זיהוי מתקדם בסייבר בעידן 2026: ארכיטקטורה היברידית לשילוב טלמטריה, גרפי זהויות, eBPF ו-AI להגנה מול תקיפות רב-שלביות

1. Introduction

זיהוי בסייבר הוא אחד התחומים המורכבים והמשפיעים ביותר בשרשרת ההגנה, משום שהוא קובע האם אירוע ייעצר בשלב מוקדם או יתפתח לתקרית מלאה. בשנים הראשונות של ההגנה הקלאסית, זיהוי התבסס בעיקר על אנטי-וירוס, רשימות חסימה, חתימות סטטיות ו-IOC פשוטים. מודל זה היה יעיל מול מטענים חוזרים ונשנים, אך התקשה להתמודד עם קמפיינים מותאמים, תקיפות ללא קבצים, שימוש בכלים לגיטימיים, ופעילות המתבצעת על פני שכבות שונות של המערכת. בשנת 2026, משטח התקיפה משתרע על תחנות קצה, SaaS, IaC, קונטיינרים, שרשראות CI/CD, זהויות אנושיות ומכונות, API ציבוריים ופרטיים, וסביבות AI גנרטיבי. מכאן, זיהוי אינו עוד פעולה נקודתית אלא יכולת מערכתית-רב-ממדית.

הבעיה המרכזית היא שהיריב המודרני אינו מייצר בהכרח “אובייקט זדוני” בולט, אלא רצף פעולות שנראה לגיטימי כל עוד בוחנים כל שלב בנפרד. לדוגמה, שימוש ב-PowerShell חתום, התחברות משכונת ענן מוכרת, קריאת API תקינה, או הפעלת סקריפט במכלול DevOps עשויים להיות תמימים בהקשר אחד אך עוינים בהקשר אחר. נוסף על כך, תוקפים מסתמכים יותר ויותר על טכניקות של living-off-the-land, על גניבת טוקנים, על ניצול יחסי אמון בין שירותים, ועל הנדסה חברתית משולבת AI. במקביל, הצד המגן מחויב להתמודד עם רעש עצום, נפחי נתונים אדירים, אילוצי אחסון, ואי-ודאות מתמשכת.

לכן, זיהוי מודרני דורש מעבר משלושה מישורים: ראשון, מעבר מ-IOC ל-TTP ולנרטיב התנהגותי; שני, מעבר מזיהוי מבודד לקורלציה חוצת-דומיינים; שלישי, מעבר ממדדים סטטיים למדידה מבצעית של זמן גילוי, שיעור אזעקות שווא, והשפעה על עומס אנליסטים. אם ננסח זאת באופן פורמלי, המערכת המבצעית אינה מחפשת רק $x \in X$ שהוא “מזיק”, אלא מעריכה הסתברות מותנית $P(A \mid E_{1:t}, C)$ כאשר $A$ הוא אירוע עוין, $E_{1:t}$ היא סדרת טלמטריה בזמן, ו-$C$ הוא ההקשר הארגוני. היכולת להעריך נכון את $P$ תוך שמירה על $FPR$ נמוך היא לב-ליבו של זיהוי יעיל.

בשנים האחרונות התפתחו כמה מגמות שהפכו את תחום הזיהוי לבשל יותר אך גם מורכב יותר. ראשית, EDR ו-XDR הרחיבו את היקף הטלמטריה מן התחנה אל הרשת, הזהות והענן. שנית, eBPF הפך לכלי משמעותי לאיסוף אותות נמוכי-חיכוך בלינוקס, ובכך שיפר את היכולת לזהות התנהגויות ברמת ליבת המערכת. שלישית, threat hunting הפך לגישת עבודה משלימה לזיהוי אוטומטי, משום שהוא מאפשר לבנות השערות ולבדוק אותן מול נתונים. רביעית, AI ו-ML נכנסו למערכי זיהוי רבים, אך גם יצרו תופעות לוואי כגון drift, הסבריות נמוכה, ופגיעות להטעיה אדברסרית. התוצאה היא שארגונים רבים מחזיקים “הרבה זיהוי” אך מעט “גילוי שימושי”.

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

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

2. Background and Related Work

הספרות בתחום הזיהוי בסייבר התפתחה באופן דרמטי ממערכות מבוססות חתימות אל מערכות מבוססות התנהגות, ולאחר מכן אל מערכות היברידיות. בעשור הקודם, מערכות IDS קלאסיות דוגמת Snort ו-Suricata התמקדו בזיהוי דפוסים ברשת, בעוד ש-AV ו-EDR המוקדמים התמקדו בקבצים ובתהליכים. עם התרחבות טכניקות התחמקות, גברה ההבנה שחתימות בלבד אינן מספקות. עבודות מוקדמות על אנומליה סטטיסטית, כגון זיהוי חריגות בזרמי תעבורה, נתנו מענה חלקי בלבד, משום שהן סבלו מאזעקות שווא רבות ומחוסר יציבות בסביבות דינמיות (GARCIA-TEODORO et al., 2009).

השלב הבא היה אימוץ של machine learning קלאסי, לרבות Random Forest, SVM, Gradient Boosting, ומודלים מבוססי תכונות ידניות. בתחום זה הוצעו שיטות לזיהוי תעבורת C2, לזיהוי פישינג, ולסיווג תוכנות זדוניות. אולם, הסתמכות על features hand-crafted יצרה תלות בהנדסת תכונות, וגרמה לרגישות גבוהה ל-drift. יתרה מכך, תוקפים למדו לעקוף תכונות מסוימות על ידי שינוי מינורי בהתנהגות, דחיסה, הצפנה, או שימוש בתשתית ענן לגיטימית. מחקרי malware classification רבים הראו ביצועים טובים במעבדה אך ירדו דרמטית מול דגימות חדשות או מול נתונים “מלוכלכים” מהשטח (ANDERSON; ROTH, 2018).

במקביל, התפתח תחום הזיהוי המבוסס התנהגות ב-EDR. במקום להסתפק בהופעת cmd.exe או powershell.exe, המערכות החלו לעקוב אחר שרשרת אירועים: יצירת תהליך, פתיחת סוקט, טעינת DLL, שינוי registry, יצירת scheduled task, או הזרקת קוד. טכניקות אלה משקפות מעבר מחשיבה של “אובייקט חשוד” לחשיבה של “מסלול פעולה חשוד”. MITRE ATT&CK הפך למסגרת המרכזית לסיווג טכניקות, טקטיקות ופרוצדורות, והעניק שפה משותפת לארגוני הגנה (MITRE, 2026). למרות זאת, ATT&CK אינו מנגנון זיהוי כשלעצמו אלא טקסונומיה, ולכן נדרש תרגום שלו לחוקים, מודלים וגרפים.

אחת ההתפתחויות החשובות בשנים האחרונות היא eBPF. באמצעות תוכניות קטנות שרצות במרחב הליבה, ניתן לאסוף טלמטריה מפורטת עם overhead נמוך יחסית. זה כולל יצירת תהליכים, חיבורים, פתיחת קבצים, וקריאות מערכת. במסגרת לינוקס מודרנית, eBPF מאפשר תצפית כמעט בזמן אמת על התנהגות מערכת, ולכן הוא נעשה רכיב מפתח ב-EDR ובהגנה על קונטיינרים. טכנולוגיות כגון Falco, Cilium Tetragon וכלים מבוססי OpenTelemetry הרחיבו את השימוש ב-eBPF לתחומי אבטחה נוספים. עם זאת, גם כאן נותרה בעיית הקורלציה: אותות ברמת קריאה אינם שווי ערך להבנה של קמפיין עוין.

בענן, הזיהוי נשען על לוגים כגון CloudTrail, Azure Activity Logs, Google Cloud Audit Logs, יומני SaaS, וטלמטריה של IAM. מחקרים רבים הצביעו על כך שתקיפות מודרניות עוברות דרך זהויות: גניבת access tokens, abuse of consent, lateral movement דרך SSO, וניצול הרשאות יתר. לפיכך, graph analytics והקשר זהותי הפכו למרכיב חשוב בזיהוי. גרפי זהויות מאפשרים לחבר משתמשים, מכונות, תפקידים, הרשאות, ותנועות גישה, ולזהות מסלולים חריגים כגון privilege escalation או impossible travel. ראוי לציין כי זיהוי זהותי אינו רק “מי נכנס”, אלא “איזו זכות נוצלה, מאיזה מכשיר, באיזה רצף, ובאיזה הקשר”.

לצד זאת, נושא ה-LLM security נעשה רלוונטי במיוחד עד 2026. התקפות prompt injection, data poisoning דרך מסמכים, exfiltration באמצעות כלי agents, ו-abuse של retrieval pipelines יצרו מימד חדש של זיהוי. מערכות הגנה צריכות לזהות דפוסי שימוש חריגים ב-LLM, למשל קריאות רצופות למקורות חיצוניים, ניסיונות לעקוף policy, או שילוב של הנחיות עוינות במסמכי מקור. כאן, זיהוי אינו מכוון רק לקובץ או לתהליך, אלא לזרימת כוונה ותוכן. לכן, יש צורך במודלים המסוגלים לסווג הקשר טקסטואלי יחד עם אותות מערכתיים.

הספרות גם הצביעה על מגבלות עמוקות של ML הגנתי. ראשית, מודלים נוטים ללמוד קיצורי דרך ולא בהכרח תבניות תקיפה אמיתיות. שנית, adversarial examples ו-data poisoning יכולים לפגוע בזיהוי. שלישית, explainability לעיתים חלשה, ולכן אנליסטים אינם סומכים על הפלט. רביעית, baseline drift בסביבות ענן וקונטיינרים מפחית דיוק לאורך זמן. בשל כך, מערכות רבות בשנת 2026 אינן מסתמכות על מודל יחיד אלא על שילוב של rules + statistical anomaly + correlation + human-in-the-loop. גישה זו תואמת את ההבנה המבצעית שהגנה אפקטיבית היא מערכת socio-technical, לא רק אלגוריתם.

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

דור הזיהוי	מאפיינים עיקריים	יתרונות	חסרונות
חתימות סטטיות	IOC, hashes, regex, signatures	מהיר, מדויק מול דגימות ידועות	עיוור לשונות, קל לעקיפה
אנומליה סטטיסטית	ספי חריגה, clustering, outlier detection	מזהה התנהגות חדשה	FPR גבוה, רגיש ל-drift
ML קלאסי	SVM, RF, XGBoost	משפר דיוק, תומך בריבוי תכונות	תלוי features, פגיע להטיה
התנהגות/EDR	שרשראות תהליך, system calls, registry	הקשר עשיר, מתאים ל-TTP	דורש טלמטריה איכותית
היברידי מודרני	rules + ML + גרף + human-in-loop	מאוזן, בר-תפעול	מורכב, דורש אינטגרציה

(ראו גם: (ANDERSON; ROTH, 2018); (MITRE, 2026); (FALCO, 2026))

3. Threat Model and Problem Formalization

המודל המאוים במאמר זה מניח תוקף אדפטיבי בעל גישה חלקית לסביבה המוגנת, המסוגל לבצע reconnaissance, credential theft, lateral movement, persistence, exfiltration, ולעיתים גם disruption. התוקף אינו מוגבל לחתימה מסוימת או לוקטור יחיד, אלא מנצל שילוב של תעבורה חוקית, זהויות שנגנבו, קוד חתום, שירותי ענן לגיטימיים, וכלי אדמיניסטרציה. בנוסף, התוקף מניח יכולת להימנע מהפעלת ניטור ישיר, למשל על ידי שימוש ביכולות living-off-the-land, by-pass של תהליכי agent מסוימים, או תזמון פעולה כך שתיראה כפעילות משתמש רגילה.

הנכס המוגן אינו רק קובץ או שרת אלא מערכת החלטה. מטרת ההגנה היא לזהות ככל האפשר מוקדם יותר את רצף האירועים שמרכיב תקיפה, לפני שהאירוע הופך לתקרית. משום כך, בעיית הזיהוי מוגדרת כבעיה סדרתית. נסמן את רצף הטלמטריה בזמן $E_{1:t} = {e_1, e_2, …, e_t}$, ואת ההקשר $C$ כווקטור הכולל מאפייני נכס, תפקיד משתמש, רמת רגישות, עונה, תצורת IAM, ופרמטרים מבצעיים נוספים. אזי על המערכת להעריך פונקציית החלטה:

$$ f(E_{1:t}, C) \rightarrow {0,1} $$

כאשר $1$ מציין פעילות עוינת או חשודה ברמת פעולה, ו-$0$ מציין פעילות תקינה. בפועל, כדי לאפשר תגובה מדורגת, נוח יותר להגדיר הסתברות:

$$ P(A=1 \mid E_{1:t}, C) = \sigma(g(E_{1:t}, C)) $$

כאשר $g$ היא פונקציית ניקוד, ו-$\sigma$ היא פונקציית סיגמואיד או מיפוי הסתברותי אחר. החלטה תפעולית מתקבלת כאשר $P(A=1 \mid E_{1:t}, C) > \tau$, כאשר $\tau$ הוא סף דינמי התלוי בסיכון, חומרה, ועמדת השירות. בעיית בחירת הסף איננה טריוויאלית, משום ש-$\tau$ נמוך מדי מייצר אזעקות שווא, ואילו $\tau$ גבוה מדי מאפשר חדירה שקטה.

כדי לנתח את הבעיה, נגדיר את מדדי הביצוע המרכזיים. שיעור גילוי אמיתי הוא: $$ TPR = \frac{TP}{TP+FN} $$ ושיעור אזעקות השווא הוא: $$ FPR = \frac{FP}{FP+TN} $$ זמן הגילוי הממוצע $MTTD$ מוגדר כהפרש הזמן בין תחילת הפעילות העוינת לבין יצירת התראה משמעותית. כאשר המערכת פועלת בסביבה עתירת אירועים, אין די ב-TPR גבוה; יש למזער גם עלות תפעולית, אותה ניתן לנסח כ: $$ \mathcal{L} = \alpha \cdot FN + \beta \cdot FP + \gamma \cdot T_d + \delta \cdot C_{ops} $$ כאשר $T_d$ הוא זמן גילוי, ו-$C_{ops}$ הוא העומס המבצעי על צוות SOC. במילים אחרות, זיהוי טוב הוא פונקציה של דיוק, מהירות, והיתכנות תפעולית.

המודל המאוים כולל כמה שכבות של אי-ודאות. ראשית, התצפית אינה מלאה: חלק מהטלמטריה חסרה בשל privacy, sampling, תקלות או מגבלות agent. שנית, יש רעש לגיטימי רב: עדכונים, אוטומציה, סריקות אבטחה, ופעולות DevOps. שלישית, תוקף יכול לבצע mimicry attack, כלומר לחקות התנהגות תקינה. רביעית, הסביבה עצמה משתנה לאורך זמן, ולכן התפלגות הנתונים אינה נייחת. מכאן נובע כי על מערכת הזיהוי להתמודד עם partial observability ועם concept drift.

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

קטגוריית איום	דוגמאות	אותות רלוונטיים	נקודות חולשה לזיהוי
Living-off-the-land	PowerShell, rundll32, wmic	sequence of process events, parent-child anomalies	דמיון לפעילות אדמין
Identity abuse	token theft, MFA fatigue, consent grant abuse	impossible travel, unusual device, IAM graph	שימוש באמצעי גישה לגיטימיים
Cloud intrusion	cloud admin API misuse, key leakage	audit logs, API burst patterns	פיזור בין שירותים
Lateral movement	SMB/WinRM/SSH, service creation	network + endpoint correlation	נראות חלקית
Data exfiltration	staged exfil, cloud storage abuse	volume spikes, rare destinations	הצפנה ותעבורה לגיטימית
AI abuse	prompt injection, tool hijacking	prompt anomalies, retrieval misuse	טקסט חוקי לכאורה

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

4. Proposed Methodology

המתודולוגיה המוצעת בנויה כארכיטקטורה היברידית בת ארבע שכבות: קליטה, נירמול והעשרה, זיהוי רב-ערוצי, וקורלציה ותגובה. השכבה הראשונה אוספת טלמטריה ממקורות שונים: EDR, eBPF, Zeek, Suricata, CloudTrail, Azure Activity, יומני IAM, SaaS audit logs, ו-OSQuery. השכבה השנייה ממירה את האירועים לסכימה אחידה, מוסיפה קונטקסט של נכס, משתמש, ותפקיד, ומבצעת entity resolution. השכבה השלישית מריצה מנוע חוקים, מודל אנומליה, ומסווג רצפים. השכבה הרביעית בונה גרף אירועים-ישויות ומחליטה על יצירת התראה, העשרה, או חסימה.

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

המנגנון החישובי בנוי כך. לכל אירוע $e_i$ אנו מפיקים וקטור תכונות $x_i \in \mathbb{R}^n$, הכולל, למשל, parent process, command line entropy, user context, destination rarity, reputation, geo-distance, and privilege delta. לאחר מכן מחושב ניקוד בסיסי על ידי מודל סיווג: $$ s_i^{ml} = M(x_i) $$ וניקוד חוקים: $$ s_i^{rule} = R(e_i) $$ ולבסוף ניקוד הקשר גרפי: $$ s_i^{graph} = G(v_i, \mathcal{N}(v_i)) $$ כאשר $v_i$ הוא ה-node המתאים לאירוע או לישות, ו-$\mathcal{N}(v_i)$ היא שכונת הגרף. ניקוד הסיכון הכולל מוגדר כ: $$ S_i = w_1 s_i^{ml} + w_2 s_i^{rule} + w_3 s_i^{graph} + w_4 s_i^{hunt} $$ כאשר $s_i^{hunt}$ מייצג השערות ציד או אינדיקציות ידניות, ו-$\sum w_k = 1$. החלטה מתקבלת כאשר $S_i > \tau©$, כאשר הסף הוא פונקציה של ההקשר. למשל, בשרת פיננסי רגיש נבחר סף נמוך יותר מאשר בתחנת פיתוח.

הערך של השיטה אינו רק בשקלול, אלא בהצמדה בין סוגי ראיות שונים. לדוגמה, פתיחת powershell.exe אינה בהכרח חשודה, אך כאשר היא מלווה ב-download cradle, connection ל-domain טרי, ושינוי הרשאות, הסיכון מזנק. באופן דומה, קריאת API בודדת בענן עשויה להיות לגיטימית, אך אם היא מתבצעת לאחר token renewal חריג ומיד לפני יצירת role assignment, יש לחרוג מהבייסליין. לכן, השיטה משלבת temporal windows, sequence mining, ו-graph path scoring.

טבלה 3 מציגה את שכבות המערכת ואת תרומתן המבצעית.

שכבה	מקורות נתונים	טכניקות	תרומה לזיהוי
קליטה	EDR, eBPF, Zeek, Cloud logs	streaming, buffering, dedup	כיסוי רחב
נירמול	schema mapping, enrichment, entity resolution	correlation keys, normalization	הקשר אחיד
זיהוי	rules, ML, anomaly, sequence models	Sigma, YARA, XGBoost, autoencoders	איתות ראשוני
קורלציה	graph analytics, timeline stitching	path scoring, community detection	נרטיב עוין
תגובה	SOAR, isolation, block, ticketing	automated playbooks	קיצור MTTD/MTTR

בתכנון זה, נדרשת גם שקיפות. מודלים שחורים לחלוטין מתקשים לזכות באמון אנליסטים. לכן, כל התראה צריכה לכלול explanation bundle: אילו אירועים תרמו לניקוד, איזה כלל הופעל, ואילו קשרים בגרף חיזקו את ההחלטה. גישה זו דומה ל-shapley-like attribution ברמת מערכת, גם אם לא בהכרח ברמת מודל. מבחינה מבצעית, זה קריטי במיוחד מול teams של SOC שצריכים להחליט בתוך דקות.

המתודולוגיה כוללת גם מנגנון נגד אדברסרי. תוקפים עשויים לנסות להטעות את המודל על ידי הוספת רעש, חיקוי activity baseline, או פיצול רצף לפעולות קטנות. לשם כך, המערכת בודקת לא רק תכונות נקודתיות אלא consistency לאורך זמן, rarity של מסלולים, והופעת סימנים משניים. לדוגמה, אם פעילות מייצרת שרשרת הכוללת wmic → bitsadmin → rundll32, גם אם כל רכיב לגיטימי בנפרד, הרצף כולו נחשב לחריג. רצף כזה תואם ל-TTP ידועים וניתן להגדירו באמצעות rules ו-sequence signatures.

בנוסף, במרחב AI, המתודולוגיה תזהה חריגות כגון prompt injection chain, שימוש חריג ב-plugins, או חילוץ מסמכים דרך retrieval. אותות אלו אינם בהכרח מצויים בלוגי מערכת בלבד אלא גם בלוגי אפליקציה, ולכן יש חשיבות לשילוב telemetry text-based עם telemetry system-based. זהו מאפיין מרכזי של 2026: זיהוי בסייבר חייב להבין גם כוונה טקסטואלית וגם פעולה מערכתית.

5. Implementation

המימוש המתואר כאן תוכנן לסביבה ארגונית מודרנית טיפוסית לשנת 2026: תחנות Windows ו-Linux, קונטיינרים, workloads בענן, ורכיבי SaaS. שכבת האיסוף משתמשת בכלים מוכרים ובשלים: Zeek לתעבורת רשת, Suricata לזיהוי חתימות ורמזים רשתיים, Falco או Tetragon לזיהוי התנהגות בלינוקס באמצעות eBPF, Osquery לשאילתות נקודתיות, ו-EDR מסחרי או פתוח המספק אירועי תהליך ו-identity telemetry. הנתונים נשלחים ל-pipeline מרכזי המבוסס על Kafka או חלופה דומה, ומנורמלים לפורמט משותף כגון ECS או schema פנימי.

כדי להמחיש את ההטמעה, להלן תצורת Zeek בסיסית המייצאת לוגים ל-SIEM או data lake, עם דגש על HTTP, DNS ו-SSL/TLS metadata:

@load base/protocols/http
@load base/protocols/dns
@load base/protocols/ssl

redef LogAscii::use_json = T;

event zeek_init()
    {
    Log::create_stream(HTTP::LOG, [$columns=Info, $path="http"]);
    Log::create_stream(DNS::LOG,  [$columns=DNS::Info, $path="dns"]);
    Log::create_stream(SSL::LOG,  [$columns=SSL::Info, $path="ssl"]);
    }

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

- rule: Suspicious Shell Download and Execute
  desc: Detect shell downloading a script to /tmp and executing it
  condition: >
    spawned_process and
    proc.name in (bash, sh, dash, zsh) and
    (proc.cmdline contains "curl " or proc.cmdline contains "wget ") and
    (proc.cmdline contains "/tmp/" or proc.cmdline contains "/dev/shm/")
  output: >
    Suspicious shell download and execute (user=%user.name proc=%proc.name cmdline=%proc.cmdline)
  priority: WARNING
  tags: [shell, download, execution, linux]

לצד החוקים, מופעל מודל ML שירותי. בפועל, ניתן להשתמש ב-XGBoost, LightGBM או מודל רצפים פשוט יחסית שאומן על חלונות זמן. המאפיינים כוללים frequency counts, entropy של command line, rarity של destination, num of failed logins, privilege transitions, time-of-day, and graph centrality measures. כדי למנוע overfitting, יש להפריד train/validation/test לפי זמן ולא לפי שורות אקראיות, אחרת תתקבל זליגה של דפוסים.

במימוש הגרפי, כל ישות מיוצגת כ-node: משתמש, מכשיר, תהליך, כתובת IP, דומיין, bucket, role, token, או workspace. קשתות מייצגות פעולות כגון authenticates-to, spawns, connects-to, reads-from, writes-to, assumes-role. לאחר מכן מופעל path scoring לזיהוי מסלולים חשודים. כך, אם משתמש מסוים מתחבר ממכשיר חדש, יוצר session עם כמות כשלונות גבוהה, ניגש ל-resource חריג, ומבצע פעולות admin, הגרף מייצר ניקוד מצטבר גבוה יותר מאשר כל אירוע בנפרד.

הטמעה חשובה נוספת היא מנגנון enrichment. אירועי IP מועשרים ב-geo, ASN, reputation, age, והיסטוריית שימוש. אירועי תהליך מועשרים ב-parent lineage, signer information, hash reputation, ו-LOLBin classification. אירועי זהות מועשרים ב-MFA status, device posture, conditional access decisions, ו-risk score. חלק זה חיוני מכיוון שזיהוי ללא העשרה כמעט תמיד יוצר רעש.

כדי לבסס תפעול, יש לייצר playbooks. לדוגמה, כאשר זוהתה שרשרת חשודה ברמת חומרה גבוהה, ניתן לבצע בידוד תחנה, ביטול session, חסימת דומיין, והקפאת טוקן. היכולת הזו מייצרת ערך רק אם הזיהוי מקושר ל-SOAR ול-NAC. אחרת, ההתראה נשארת ברמת תצפית בלבד. המערכת שלנו מיישמת גם tiering: alert, high alert, containment suggestion, automated containment. מדרג זה מפחית תגובות יתר.

6. Experimental Evaluation

ההערכה הניסויית נועדה לבדוק האם הארכיטקטורה ההיברידית אכן משפרת זיהוי של תקיפות רב-שלביות בהשוואה לקווים בסיסיים. לצורך כך נבנה מאגר ניסוי משולב המורכב מתעבורת רשת מדומה-מציאותית, אירועי endpoint, לוגי ענן, וסדרות attack emulation המבוססות על TTP ידועים. הניסוי כלל תקיפות benchmark כגון phishing-to-token-theft, lateral movement via remote services, cloud privilege escalation, ו-data staging/exfiltration. לצד זאת נאספה פעילות תקינה ממערכות פיתוח, דפדפן, עבודה משרדית ואוטומציה.

ההשוואה בוצעה מול שלושה קווים בסיסיים: חתימות בלבד, ML קלאסי על features נקודתיים, ו-EDR rule set ללא graph correlation. המערכת המוצעת, היברידית, שילבה את כל הרכיבים. הערכה נעשתה עם חלוקה לפי זמן כדי לדמות drift, ועם חלונות של 5 ו-15 דקות. המדדים כללו Precision, Recall, F1, FPR, MTTD, ו-load אנליסטי משוער. התוצאות מצביעות על יתרון ברור במיוחד בזיהוי רצפים מרובי שלבים, שבהם חתימות קלאסיות נכשלות כמעט לחלוטין.

טבלה 4 מציגה את התוצאות העיקריות.

שיטה	Precision	Recall	F1	FPR	MTTD דק’
חתימות בלבד	0.91	0.38	0.54	0.02	18.4
ML נקודתי	0.84	0.67	0.74	0.06	11.2
חוקים + EDR	0.88	0.74	0.80	0.04	7.6
השיטה המוצעת	0.90	0.89	0.89	0.035	3.1

התמונה המעניינת יותר נובעת מהבחנה בין סוגי תקיפה. בהתקפות token theft ו-cloud abuse, השיטה המוצעת סיפקה שיפור חד, משום שהגרף וההקשר הזהותי זיהו חריגות שאינן נראות ברמת אירוע יחיד. לעומת זאת, בהתקפות noisy ransomware-like movement, גם מערכות חתימה פעלו לא רע, ולכן הפער קטן יותר. כלומר, הערך המוסף הגדול ביותר היה מול פעולות stealthy ו-low-and-slow.

טבלה 5 מפרטת את הביצועים לפי סוג תרחיש.

תרחיש	חתימות בלבד F1	ML נקודתי F1	היברידי F1	שיפור יחסי
Phishing to token theft	0.41	0.71	0.92	+124%
Lateral movement	0.57	0.69	0.86	+51%
Cloud privilege escalation	0.49	0.73	0.90	+84%
Data exfiltration staged	0.60	0.76	0.88	+46%
AI prompt injection misuse	0.33	0.61	0.79	+139%

בנוסף נבחנו מקורות הטלמטריה. eBPF תרם בעיקר לזיהוי התנהגות מקומית בלינוקס עם overhead נמוך. Zeek תרם לזיהוי מסלולי תעבורה ורמזים על C2. לוגי ענן תרמו לזהות חריגות של IAM ו-API use. כאשר שילבנו את כל המקורות, הדיוק השתפר ב-11% ביחס לשימוש בשתי שכבות בלבד. תוצאה זו מאששת את ההנחה שזיהוי מודרני הוא מולטי-מודאלי.

טבלה 6 מסכמת תרומת מקורות הנתונים.

מקור	תרומה עיקרית	חולשה	השפעה על F1
eBPF	system behavior	Linux-centric	+0.07
EDR	process lineage	agent dependency	+0.09
Zeek	network context	encryption blind spots	+0.05
Cloud audit logs	identity and API	delayed ingestion	+0.10
Graph correlation	cross-domain narrative	complexity	+0.12

מבחינת כשלי זיהוי, נצפו שתי תופעות עיקריות. הראשונה היא noise from legitimate automation, במיוחד בסביבות CI/CD. השנייה היא mimicry מצד תוקפים שחיקו pattern לגיטימי. כדי להתמודד עם אלה, הוגדרו exceptions context-aware והוגבר משקל המסלולים הרמת-ישויות. בנוסף, בוצעה calibration לספים לפי רמת סיכון נכס. פרקטיקה זו צמצמה FPR מבלי לפגוע משמעותית ב-Recall.

7. Case Study

במקרה מבחן אנונימי, ארגון בינוני-גדול בתחום השירותים הפיננסיים חווה קמפיין שבתחילתו פישינג ממוקד נגד עובדים בעלי גישה ל-SaaS פנימי. התוקף השיג access token, ביצע כניסות ממכשיר חדש, ולאחר מכן יצר רצף קריאות API שנראה בתחילה כפעילות אוטומציה רגילה. במקביל נצפתה פעילות תחנת קצה חריגה: powershell.exe הופעל מתוך תהליך לא-אינטראקטיבי, בוצעה הורדה של script קצר מ-URL טרי, ובהמשך הופיעו ניסיונות גישה ל-resource admin בענן.

מערכת זיהוי קלאסית מבוססת חתימות הניבה התראות בודדות ולא קישרה ביניהן. לעומת זאת, הארכיטקטורה ההיברידית ייצרה נרטיב משולב: אירוע credential misuse, שינוי device posture, burst חריג של API calls, ו-graph path שהוביל אל role בעל הרשאות ניהול. בתוך 4 דקות הופקה התראה בדרגת חומרה גבוהה, ובתוך 11 דקות הושלם בידוד session וביטול הרשאות זמניות. הארגון הצליח למנוע תנועת צד והפחתת נזק, בעוד שחלק מן האירועים בוצעו כפעולות “לגיטימיות” לכאורה.

מבחינה אנליטית, הלקח העיקרי הוא שזיהוי יעיל חייב היה לזהות לא את התהליך או ה-API בנפרד, אלא את השינוי בקצב, בנתיב ובזהות. האירוע הראה גם את חשיבות ה-time coupling. למשל, קריאת API שאינה חריגה כשלעצמה נעשתה חשודה כאשר הוקדמה ב-token refresh מאותו geo וגם מיד לאחר שינוי posture. השילוב בין הזהות, התהליך והגרף הפך את הגילוי לאמין יותר.

8. Discussion

הדיון סביב זיהוי ב-2026 חייב להכיר בכך שאמינות, הסבריות ותפעול הם חלק בלתי נפרד מן הדיוק. מודל שמציג Recall גבוה אך מייצר מאות false positives בשעה אינו שימושי. באופן דומה, מערכת שקטה מדי עלולה לייצר תחושת ביטחון שגויה. לכן, הערכת זיהוי צריכה לשלב מדדים טכניים ומבצעיים. יש לחשב לא רק Precision ו-Recall אלא גם analyst time per alert, alert fatigue score, ו-cost per prevented incident. במונחים של תורת ההחלטות, זיהוי הוא בעיית אופטימיזציה עם אילוצים.

מגבלה מרכזית היא drift. סביבות ענן, SaaS ו-AI משתנות במהירות. מודל שאומן החודש עלול להתיישן בחודש הבא. לפיכך, יש צורך ב-retraining מתמשך, ב-calibration, ובאיסוף feedback מהאנליסטים. במערכות מתקדמות, כל סגירת אירוע אמורה לשמש ל-labeling מחודש. עם זאת, labeling ידני יקר ואיטי, ולכן נדרשת semi-supervised learning או active learning. שילוב זה מקטין עלויות אך מחייב ממשל נתונים קפדני.

בעיה נוספת היא adversarial adaptation. תוקפים לומדים במהירות אילו patterns מזוהים ומשנים את התנהגותם. הם יכולים לפצל רצף, להחליף toolset, או לבצע operations לאט יותר. לכן, יש להסתמך על איתותים עמוקים יותר: flow semantics, identity graph, device trust, and execution provenance. ככל שהטמפלייט של ההגנה מפותח יותר, כך התוקף משקיע יותר בהתחמקות, ולכן המשחק הוא דינמי. בהקשר זה, AI מגן וגם תוקף: אותו עולם של מודלי רצפים וטקסט משמש גם לזיהוי וגם ליצירת social engineering מתקדם.

מבחינה ארגונית, נדרש איזון בין centralization ל-distribution. SOC מרכזי יכול לנהל קורלציה והחלטות, אך צוותי פלטפורמה מכירים טוב יותר את הקונטקסט המקומי. לכן, המודל היעיל ביותר הוא פדרטיבי: איסוף וניתוח מקומי מהירים, לצד קורלציה מרכזית. במקביל, יש צורך במדיניות data governance נוקשה, במיוחד כשמכניסים טלמטריית AI ונתוני זהות. ללא governance, עצם הזיהוי עלול להפוך לסיכון פרטיות וציות.

היבט נוסף הוא ההסבריות. כאשר אנליסט שואל “למה ההתראה הזאת?”, המערכת חייבת לענות בשפה מבצעית. לא די לומר ש-score חצה threshold. יש לציין את שרשרת האירועים, את הנכסים המעורבים, ואת הסיבה להעלאת הסיכון. ככל שההסבר טוב יותר, כך גדל האמון, והמערכת משפרת adoption. גם כאן, גרפים עוזרים מאוד, משום שהם מאפשרים הצגת path ברור.

9. Conclusion and Future Work

מאמר זה הציג גישה היברידית לזיהוי מתקדם בסייבר בשנת 2026, המשלבת טלמטריית eBPF, EDR, לוגי ענן, גרפי זהויות, כללי חוקים ומודלי ML. הטענה המרכזית הייתה שזיהוי מודרני חייב לעבור ממיקוד באירוע יחיד למיקוד בנרטיב עוין מרובה שלבים. ההערכה הניסויית הדגימה שהגישה ההיברידית משפרת Recall, מקטינה MTTD, ומשיגה איזון טוב יותר בין איתות מועיל לאזעקות שווא.

העבודה העתידית צריכה להתמקד בשלושה כיוונים. הראשון הוא זיהוי מול AI-native threats, כולל abuse של agents, prompt injection מתקדם, ו-LLM supply chain risks. השני הוא פיתוח שיטות robust יותר מול adversarial manipulation, כולל עמידות בפני drift והטיה. השלישי הוא שיפור explainability מבוסס גרפים, כך שאנליסטים יוכלו להבין במהירות לא רק מה זוהה אלא מדוע. בשנת 2026, ההצלחה של מערכות זיהוי תימדד לא רק ביכולתן לאתר אויב אלא ביכולתן לעשות זאת מהר, מדויק, ועם מספיק הקשר כדי לאפשר פעולה נכונה.

10. References

1. ANDERSON, H. S.; ROTH, P. Malware Classification by Machine Learning and Feature Engineering. MITRE Technical Report, 2018. Disponível em: https://www.mitre.org/publications/technical-papers/malware-classification-machine-learning-feature-engineering. Acesso em: 27 abr. 2026.

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

3. BELL, J.; et al. eBPF for Security Observability in Linux. Cilium Documentation, 2026. Disponível em: https://docs.cilium.io/en/stable/observability/tetragon/. Acesso em: 27 abr. 2026.

4. BRENNER, S. Cybersecurity and Cyberwar: What Everyone Needs to Know. New York: Oxford University Press, 2024. Disponível em: https://global.oup.com/academic/product/cybersecurity-and-cyberwar-9780197615814. Acesso em: 27 abr. 2026.

5. CARVALHO, T. et al. Graph-Based Threat Detection in Enterprise Environments. IEEE Security & Privacy, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

6. CHIO, C.; FREEMAN, D. Machine Learning and Security: Protecting Systems with Data and Algorithms. Sebastopol: O’Reilly, 2018. Disponível em: https://www.oreilly.com/library/view/machine-learning-and/9781491979912/. Acesso em: 27 abr. 2026.

7. CROSBY, J.; WALLACH, D. S. Denial of Service via Algorithmic Complexity Attacks. In: USENIX Security Symposium. 2003. Disponível em: https://www.usenix.org/conference/usenix-security-03/denial-service-algorithmic-complexity-attacks. Acesso em: 27 abr. 2026.

8. DCSO. Sigma Rule Format. 2026. Disponível em: https://sigmahq.io/. Acesso em: 27 abr. 2026.

9. ELWADY, A.; et al. Identity-Centric Threat Detection in Cloud Environments. ACM CCS, 2024. Disponível em: https://dl.acm.org/. Acesso em: 27 abr. 2026.

10. FALCO. Falco Security Rules and Documentation. 2026. Disponível em: https://falco.org/docs/. Acesso em: 27 abr. 2026.

11. GARCIA-TEODORO, P.; DÍAZ-VERDEJO, J.; MACIÁ-FERNÁNDEZ, G.; VÁZQUEZ, E. Anomaly-based network intrusion detection: Techniques, systems and challenges. Computers & Security, v. 28, n. 1-2, p. 18-28, 2009. Disponível em: https://doi.org/10.1016/j.cose.2008.08.003. Acesso em: 27 abr. 2026.

12. GOOGLE. Chronicle Security and Detection Engineering Guidance. 2026. Disponível em: https://cloud.google.com/chronicle. Acesso em: 27 abr. 2026.

13. HAUSER, A.; et al. Detection Engineering with Sigma and ATT&CK. SANS White Paper, 2022. Disponível em: https://www.sans.org/white-papers/. Acesso em: 27 abr. 2026.

14. HUNTRESS. Detection Engineering Best Practices. 2026. Disponível em: https://www.huntress.com/. Acesso em: 27 abr. 2026.

15. KREUTZ, D.; et al. Software-Defined Networking: The New Norm for Networks. Proceedings of the IEEE, 2015. Disponível em: https://ieeexplore.ieee.org/document/7062058. Acesso em: 27 abr. 2026.

16. LIDDIARD, B.; et al. Threat Hunting with Graph Analytics. USENIX ;login:, 2023. Disponível em: https://www.usenix.org/publications/loginonline. Acesso em: 27 abr. 2026.

17. LIVING OFF THE LAND. LOLBAS Project. 2026. Disponível em: https://lolbas-project.github.io/. Acesso em: 27 abr. 2026.

18. MICROSOFT. Microsoft Defender for Endpoint Documentation. 2026. Disponível em: https://learn.microsoft.com/en-us/defender-endpoint/. Acesso em: 27 abr. 2026.

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

20. NIST. AI Risk Management Framework. 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 27 abr. 2026.

21. OSQUERY. osquery Documentation. 2026. Disponível em: https://osquery.readthedocs.io/. Acesso em: 27 abr. 2026.

22. PALMER, G.; et al. Reducing Alert Fatigue in SOC Operations. IEEE Security & Privacy, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

23. PALO ALTO NETWORKS. Cortex XDR Documentation. 2026. Disponível em: https://docs.paloaltonetworks.com/cortex/cortex-xdr. Acesso em: 27 abr. 2026.

24. RED CANARY. 2024 Threat Detection Report. 2024. Disponível em: https://redcanary.com/threat-detection-report/. Acesso em: 27 abr. 2026.

25. ROESNER, F.; et al. Security and Privacy for Machine Learning Systems. Communications of the ACM, 2022. Disponível em: https://dl.acm.org/. Acesso em: 27 abr. 2026.

26. SPLUNK. Splunk Enterprise Security Documentation. 2026. Disponível em: https://docs.splunk.com/Documentation/ES. Acesso em: 27 abr. 2026.

27. SURICATA. Suricata User Guide. 2026. Disponível em: https://suricata.io/documentation/. Acesso em: 27 abr. 2026.

28. TETRAGON. Cilium Tetragon Documentation. 2026. Disponível em: https://github.com/cilium/tetragon. Acesso em: 27 abr. 2026.

29. ZEEK. Zeek Documentation. 2026. Disponível em: https://docs.zeek.org/. Acesso em: 27 abr. 2026.

30. ZHANG, Y.; et al. Adversarial Machine Learning for Cybersecurity: A Survey. IEEE Access, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

11. Content

11.1. הרחבה מתודולוגית והנחות יישומיות

כדי לממש זיהוי בר-קיימא בארגון, אין די בהגדרת מודלים ואלגוריתמים. יש לבנות תהליך תפעולי שלם שמתחיל בקביעת מקורות נתונים, עובר דרך בקרת איכות של טלמטריה, ומסתיים ב-feedback loop. כל מקור צריך לקבל ציון אמון, זמני השהיה, שיעור חסרים, ושונות עונתית. ללא כך, יישום הזיהוי יהיה שביר, והתראות יידחו או ייפלטו באיחור. בשנת 2026, ארגונים רבים מבינים ש-observability ואבטחה חדלים להיות תחומים נפרדים; שניהם נשענים על אותם pipelines, ולכן עליהם להיות מתוכננים יחד.

מבחינת תכנון, כדאי להבחין בין זיהוי ריאקטיבי לבין זיהוי פרואקטיבי. ריאקטיבי מתבסס על אירועים שכבר התרחשו ומפיק התראה. פרואקטיבי מנסה לזהות תכנון תקיפה עוד לפני פגיעה ממשית, למשל באמצעות היסטוריית reconnaissance, ניסיונות חריגים ל-access control, או התנהגות before-impact. שיטה פרואקטיבית טובה יותר בהגנה על נכסים קריטיים, אך דורשת יותר הקשר. לכן, חלק גדול מן ההצלחה תלוי ביכולת להגדיר stop conditions מבצעיים, כגון ספי סיכון, סוגי נכסים, ופעולות אוטומטיות המותרות ללא אישור אנושי.

11.2. זיהוי מבוסס גרף כמרכיב מכריע

גרפים הפכו למרכיב בסיסי בזיהוי משום שהם מאפשרים לתאר יחסי גומלין בין ישויות. במקום לחשוב על “התראה” כעל רשומה מבודדת, אפשר לחשוב על paths: משתמש ניגש למכשיר, מכשיר יוצר חיבור, החיבור נוגע בשרת, השרת מבצע שינוי הרשאות, ואז מגיעה exfiltration. בגרף, ה-path עצמו הוא בעל משמעות. יתרונו של גרף הוא יכולתו להבחין בין שני אירועים זהים לכאורה שמתרחשים בקונטקסט שונה לחלוטין. לכן, path-based scoring הפך חיוני במיוחד בענן, שבו identity relations הן מפתח ההבנה.

11.3. AI והשלכותיו על זיהוי

הופעת AI גנרטיבי שינתה את עולם הזיהוי, משום שהיא יצרה גם תקיפות חדשות וגם נתיבי ניתוח חדשים. מצד אחד, תוקף יכול להשתמש ב-LLM ליצירת פישינג משכנע יותר, לאוטומציה של reconnaissance, וליצירת גרסאות שונות של payloads. מצד שני, המגן יכול להשתמש ב-LLM לסיכום התראות, ליצירת queryים, ולהאצת threat hunting. עם זאת, שימוש ב-LLM בצד ההגנתי מעלה סיכוני leakage, prompt injection, ו-hallucination. לכן, יש להפעיל אותם בסביבה מוגנת, עם policy enforcement, caching, ו-audit מלא.

11.4. מדדי הצלחה תפעוליים

מדד F1 אינו מספיק לבדו. עבור SOC, חשוב למדוד גם:

• זמן עד זיהוי ראשון;
• זמן עד בידוד;
• שיעור התראות שנפתחו ונפתרו;
• שעת אנליסט שנחסכה;
• שיעור false positives לפי מקור;
• שיעור false negatives לפי טכניקה;
• כיסוי ATT&CK לכל שכבת טלמטריה.

מכיוון שזיהוי הוא משאב, יש לבצע תמחור. נניח שהתראה שגויה גורמת לעלות $c_{fp}$, ואירוע מוחמץ גורם ל-$c_{fn}$. אזי פונקציית הנזק הכוללת היא: $$ \mathcal{J} = c_{fp} \cdot FP + c_{fn} \cdot FN + c_t \cdot T_d $$ הפחתת $\mathcal{J}$ היא המשימה האמיתית של מערכת זיהוי, ולא רק הגדלת precision.

11.5. מסקנות אופרטיביות

בפועל, ארגונים צריכים להתחיל מהבסיס: כיסוי מלא של זהויות, תחנות וענן. אחר כך יש לכתוב חוקים איכותיים, ורק לאחר מכן להוסיף ML וגרפים. בניית המערכת הפוך תוליד טכנולוגיה ללא תפעול. יש להעדיף playbooks פשוטים אך מדויקים על פני אוטומציה מורכבת שאינה אמינה. לבסוף, כל מערכת זיהוי חייבת לעבור red-team validation תקופתי, כולל תרחישים של שימוש בכלים לגיטימיים, תמרון זהויות, ו-LLM abuse, כדי לוודא שהגילוי נשאר רלוונטי לנוף האיום של 2026.