Paper Files / Detection
Detection in Cybersecurity in 2026: A Layered, Telemetry-Centric Methodology for High-Fidelity Threat Discovery Across Endpoints, Networks, Cloud, and Identity
Detection remains the decisive control plane of cybersecurity in 2026 because prevention is no longer assumed to be complete, and modern adversaries routinely blend living-off-the-land tradecraft, identity abuse, cloud-native persistence, and AI-assisted social engineering into campaigns that evade perimeter-centric defenses. This paper presents a publication-ready research treatment of detection as an engineering discipline rather than a single product capability. We formalize detection as a probabilistic inference problem over heterogeneous telemetry, where the objective is to maximize true-positive yield under operational constraints on false positives, latency, and analyst workload. The paper synthesizes the state of the art through 2026, covering endpoint detection and response, network detection and response, identity threat detection, cloud-native detection, SIEM/XDR pipelines, eBPF-based sensors, and AI-assisted detection workflows. We then propose a layered methodology that combines deterministic indicators, behavioral analytics, ATT&CK-aligned graph features, and supervised/semi-supervised anomaly models, with explicit calibration against adversarial adaptation. The methodology is designed for environments that must operate under zero-trust assumptions, post-quantum migration pressure, and the increasing use of generative AI for phishing, deepfake-enabled fraud, and malware development. An implementation blueprint is provided using widely deployed tools and data formats such as Sigma, Zeek, Suricata, Sysmon, OpenTelemetry, and Elastic/Splunk-style pipelines. Experimental evaluation is framed around realistic enterprise datasets and red-team scenarios, with metrics including precision, recall, F1, mean time to detect, and alert density per host-day. A case study illustrates how the proposed stack detects an identity-led intrusion that pivots from phishing to token theft, cloud API abuse, and lateral movement. The paper concludes that effective detection in 2026 is not a search for universal signatures, but a continuously tuned socio-technical system that merges telemetry quality, adversary modeling, detection engineering, and feedback-driven automation.
1. מבוא
זיהוי איומים, או Detection, הוא אחד התחומים שבהם הפער בין תיאוריה לבין מציאות מבצעית עדיין ניכר ביותר. בשנת 2026 כבר ברור שאין די ב"חתימות" סטטיות, בכלי AV מסורתיים, או בהנחה שמנגנוני מניעה יספיקו כדי לעצור תוקף שמחזיק בשרשרת תקיפה גמישה, משתמש בזהויות גנובות, מפיץ פקודות דרך שירותי ענן לגיטימיים, ומטשטש את טביעותיו באמצעות לוגים חסרים, הצפנה, והפעלה של קבצים חתומים. הארגון המודרני מתמודד עם יריב שמסוגל לבחור את המשטח החלש ביותר בכל שלב: תחנת קצה, זהות, API בענן, תשתית SaaS, או שרשרת האספקה. לכן Detection הוא לא רכיב משלים; הוא מנגנון קבלת ההחלטות המרכזי שמאפשר לארגון להבין מה באמת קורה בתשתית שלו בזמן כמעט-אמת.
בשנים האחרונות הדיון על Detection עבר משפה של מוצרים לשפה של הנדסת טלמטריה. כלומר, השאלה אינה רק “האם יש לנו SIEM?” אלא “האם הנתונים הנאספים מספיק עשירים, עקביים, ניתנים לחיבור, ומכוונים לתיאור התנהגות ולא רק לאיסוף אירועים?” הניסיון המצטבר ממבצעי חדירה, חקירות פורנזיות, ו-red teaming מראה כי ארגונים רבים אוספים כמות עצומה של לוגים, אך מתקשים לייצר מהם איתותים בעלי נאמנות גבוהה. הסיבה המרכזית היא ש-Detection טוב הוא בעיית אופטימיזציה תחת אילוצים: יש למזער התראות שווא, לזהות מהר, לספק הקשר לפעולת תגובה, ולהישאר עמידים לשינוי טקטיקות התוקף. מתמטית, ניתן לנסח זאת כבחירה בפונקציית החלטה $f(x)\rightarrow y$, כאשר $x$ מייצג וקטור תצפיות רב-מקוריות ו-$y$ מסמן אם מתקיימת פעילות חשודה. המטרה אינה רק למקסם דיוק, אלא למקסם תועלת מבצעית $U$: $$ U = \alpha \cdot TP - \beta \cdot FP - \gamma \cdot MTTD - \delta \cdot C $$ כאשר $TP$ הם גילויים אמיתיים, $FP$ התראות שווא, $MTTD$ הוא mean time to detect, ו-$C$ הוא עומס תפעולי.
המאמר הנוכחי מציג את Detection כדיסציפלינה רב-שכבתית: endpoint, network, identity, cloud, application, ו-AI-assisted workflows. אנו נבנה מסגרת שמחברת בין כל אחת מהשכבות הללו באמצעות טלמטריה עשירה, מודלים התנהגותיים, ותרגום שיטתי של TTPs מ-ATT&CK לכללי זיהוי. בנוסף, נידרש למציאות של 2026: התקפות מבוססות LLM, הנדסה חברתית משופרת, deepfakes קוליים וחזותיים, שימוש גובר ב-CNAPP וב-eBPF, ותהליכי מעבר ל-post-quantum cryptography שמחייבים גם מעקב אחרי פריסת פרוטוקולים ותעודות.
2. רקע ועבודות קשורות
לזיהוי איומים יש שורשים עתיקים בהיסטוריה של אנטי-וירוס, IDS, ו-SIEM, אך העשור האחרון שינה את כללי המשחק. מסורתית, מערכות IDS כמו Snort ו-Suricata התבססו על כללים וחתימות לרשת, בעוד שתהליכי endpoint הסתמכו על AV, heuristics, ובהמשך EDR. עם התפתחות מתקפות living-off-the-land, השימוש ב-PowerShell, WMI, rundll32, mshta, regsvr32, ו-rundll32 כאמצעי ביצוע לגיטימי-לכאורה גרם לכך שחתימות בלבד אינן מספיקות. מחקרים ופרקטיקה מבצעית לאורך השנים הדגישו כי האויב מנצל תוכנות חתומות, פרוטוקולים מוצפנים, ושירותים פופולריים כדי להיטמע בתעבורה הרגילה (MITRE, 2025).
במישור התאורטי, Detection עבר משלוש תפיסות עיקריות. הראשונה היא detections based on indicators, כלומר IOC: hashes, domains, IPs, and YARA/Sigma signatures. היתרון הוא דיוק גבוה כאשר האינדיקטור טרי, אך הוא נשחק במהירות מול adversary adaptation. השנייה היא behavioral detection, המבוססת על רצפים, הקשרים, וחריגה מהתנהגות נורמלית. כאן מופיעים כלים כמו Sysmon, auditd, Zeek, Falco, Cilium Tetragon, ו-eBPF sensors, שנועדו לאסוף תצפיות עשירות בזמן ריצה. השלישית היא probabilistic and ML-based detection, המנסה ללמוד דפוסים מרובים מרשומות היסטוריות, אך סובלת מהטיות נתונים, drift, וקשיי הסבר. בפועל, ארגונים בוגרים משלבים את שלוש הגישות.
בעולם הארגוני של 2026, SIEM עדיין רלוונטי, אך כבר אינו מספיק לבדו. פלטפורמות XDR ו-CNAPP הרחיבו את פני השטח הנצפים אל endpoint, identity, cloud workload, container, and SaaS. במקביל, נוכחות eBPF כבסיס לטלמטריה עמוקה במערכות Linux שינתה את האופן שבו ניתן לעקוב אחרי syscalls, network flows, process lineage, ו-container behavior ללא overhead כבד. כלים כדוגמת Falco, Tetragon, Tracee, ויישומי observability מבוססי OpenTelemetry מאפשרים לשלב אבטחה עם תצפית תפעולית. אולם, כפי שמראים מחקרים מהשנים האחרונות, איכות הנתונים חשובה יותר מכמותם: לוגים רועשים, חסרים, או בלתי-נורמליים פוגעים ביכולת ההסקה יותר מאשר היעדר טלמטריה חלקית בלבד (NIST, 2024).
ממד נוסף הוא detection engineering. בשנים האחרונות הענף נע בין כתיבת כללים ידניים ליצירת detector pipelines ממוסדים. Sigma הפך לשפה דה-פקטו להעברת לוגיקת זיהוי בין פלטפורמות SIEM שונות, בעוד YARA נשאר קריטי במישור הסטטי למבני קבצים, payloads, ו-ransomware families. לצד זאת, frameworks כמו MITRE ATT&CK מספקים שפה משותפת למיפוי טכניקות ולקישור בין תצפיות לפעילות תוקפנית. שילוב ATT&CK עם graph-based detection מאפשר לזהות chain-of-behavior ולא אירועים בודדים. זהו מעבר מהסתכלות על “התראה” כיחידה בודדת להסתכלות על “קמפיין” כישות חישובית.
גם תחום ההונאה והטעת התוקף התפתח. Deception technologies, canary tokens, honeytokens, ו-decoy identities יוצרים שכבת גילוי יזומה. הם אינם תחליף ל-Detection מסורתי, אך הם מצוינים בהפחתת זמן השהות של תוקפים מתוחכמים, במיוחד כאשר מתקיים חיפוש רוחבי או שימוש בכלים אוטומטיים. עם זאת, יש להפעילם בזהירות כדי למנוע זיהוי על ידי התוקף או פגיעה במשתמשים לגיטימיים.
הספרות עד 2026 מצביעה גם על מעבר ל-security data engineering. ככל שהארגונים עוברים לענן, למיקרו-שירותים, ולצינורות CI/CD, ה-Detection הופך לבעיה של אינטגרציה: איך לרתום לוגים מ-Kubernetes, IAM, API gateways, data planes, browser telemetry, והתקני endpoint לתוך מערכת אחידה? כאן נכנסות into play טכנולוגיות כמו OpenTelemetry, Fluent Bit, Kafka, Elastic, Splunk, Google Chronicle, Microsoft Sentinel, ו-Wazuh. כל אחת מהן מספקת חלק מהפאזל, אך אף אחת אינה פותרת את בעיית ההחלטה עצמה.
טבלה 1: השוואת שכבות Detection מרכזיות
| שכבה | מקורות טלמטריה | יתרונות | חולשות | כלים נפוצים |
|---|---|---|---|---|
| Endpoint | Sysmon, auditd, ETW, eBPF, EDR events | ראות עמוקה לתהליכים, הורות, זיכרון | רגיש לעקיפות ולהשבתת סוכן | Microsoft Sysmon, Elastic Defend, CrowdStrike, Falco |
| Network | NetFlow, Zeek, Suricata, DNS, TLS JA3/JA4 | ראות רוחבית, זיהוי C2, Exfiltration | תעבורה מוצפנת מקשה | Zeek, Suricata, Arkime |
| Identity | Sign-in logs, token use, MFA, IAM, SSO | קריטי נגד ATO ו-session hijacking | תלוי בענן/IdP | Microsoft Entra ID, Okta, Google Workspace |
| Cloud | CloudTrail, Audit Logs, CSPM/CNAPP events | זיהוי misuse של API והרשאות | רעש גבוה, מורכבות | AWS GuardDuty, Sentinel, Wiz |
| Application | WAF, API gateway, code/runtime traces | זיהוי abuse ברמת השירות | דורש אינטגרציה עמוקה | OpenTelemetry, Kong, Envoy |
| Deception | Canary tokens, honey files, decoy creds | תפיסה מוקדמת של תוקף | חשש מפולס-פוזיטיב | Thinkst Canary, custom decoys |
במחקר עכשווי, התכונה המרכזית המשותפת היא שאף שכבה לא מספיקה לבדה. ההתקדמות האמיתית נובעת מקורלציה בין שכבות, ולא רק מהוספת מקורות מידע.
3. מודל איום והגדרת הבעיה
הבעיה שאנו מבקשים לפתור היא זיהוי פעילות עוינת בזמן, במצב שבו התוקף יודע שהוא מנוטר, ומנסה לעבור מתצפית לתצפית מבלי לייצר חתימה ברורה. לכן מודל האיום שלנו כולל ארבעה סוגי יריבים. הראשון הוא תוקף commodity שמשתמש ב-phishing kits, infostealers, ו-ransomware-as-a-service. השני הוא יריב מתוחכם יותר שמבצע initial access דרך identity compromise, token theft, או abuse של OAuth apps. השלישי הוא adversary-in-the-middle המשתמש ב-proxy-based credential interception, כולל תעבורת reverse proxy ושיבוש MFA. הרביעי הוא יריב ממוקד cloud ו-SaaS, שמעדיף API abuse, persistence via service principals, role chaining, and CI/CD compromise.
הגדרת הבעיה אינה binary classification טהורה. בהקשר מבצעי, הארגון צריך להחליט האם רצף תצפיות $X = {x_1, x_2, …, x_n}$ מייצג פעילות נורמלית, חשודה, או זדונית, ובאיזו רמת ודאות. נדרש גם לקבוע actionability: האם להתעלם, להעשיר, לפתוח חקירה, או לחסום. לכן ניתן לנסח את הבעיה כבחירה במדיניות $ \pi(a|X) $ שממפה תצפיות לפעולה $a$ מתוך קבוצה ${ignore, enrich, triage, contain, eradicate}$. המדיניות האידאלית מאזנת בין סיכון לפספוס לבין עלות תגובה מיותרת.
טבלה 2: קטגוריות איום ודרישות Detection
| קטגוריית איום | דוגמאות TTP | נכסים בסיכון | דרישת גילוי מרכזית |
|---|---|---|---|
| Phishing ו-ATO | Session theft, MFA fatigue, OAuth consent abuse | זהויות, דוא"ל, SaaS | זיהוי חריגות ב-login, token replay, impossible travel |
| Malware ו-Ransomware | Loader, persistence, lateral movement | endpoints, file servers | lineage של תהליכים, שינויי registry, encryption burst |
| Cloud abuse | IAM abuse, key leakage, API chaining | buckets, instances, secrets | audit trails, privilege escalation, anomalous API sequences |
| Lateral movement | PsExec, WMI, SMB, SSH, RDP | שרתים פנימיים | קשרי host-to-host, burst scanning, remote service creation |
| Data exfiltration | DNS tunneling, HTTPS upload, cloud sync abuse | מידע רגיש | volume anomalies, rare destinations, entropy, beaconing |
| Supply chain | CI/CD tampering, malicious dependencies | build systems, artifacts | provenance, signed builds, repo activity anomalies |
הגדרות האיכות של Detection צריכות לכלול לא רק precision ו-recall, אלא גם latency, cost, explainability, and coverage. במילים אחרות, מערכת טובה אינה רק כזו שמזהה הרבה, אלא כזו שמזהה נכון, מהר, ובצורה שמאפשרת חקירה. אם נסמן true positives ב-$TP$, false positives ב-$FP$, false negatives ב-$FN$, ו-$TN$ בהתאמה, אז: $$ Precision = \frac{TP}{TP + FP} $$ $$ Recall = \frac{TP}{TP + FN} $$ $$ F1 = 2 \cdot \frac{Precision \cdot Recall}{Precision + Recall} $$ אולם עבור SOC, ה-F1 לבדו אינו מספיק, משום ש-100 התראות ביום עם precision גבוה עלולות עדיין להיות בלתי-ניתנות לטיפול אם אינן מקושרות בהקשר. לכן מוסיפים alert density, triage time, and containment delay.
4. מתודולוגיה מוצעת
המתודולוגיה שאנו מציעים בנויה כחמש שכבות: איסוף, נירמול, העשרה, זיהוי, וקורלציה/תגובה. הרעיון המרכזי הוא שאין “מנוע זיהוי” יחיד; במקום זאת יש pipeline שמייצר candidates ברמות אמון שונות, ואז מצמצם אותם דרך הקשר. השכבה הראשונה היא telemetry ingestion, שבה נאספים אירועים מ-endpoints, identity providers, network sensors, cloud control planes, application traces, ו-deception artifacts. בשכבה זו חשוב להבטיח schema consistency באמצעות מודלים כמו ECS, CIM, או OCSF, שכן חוסר עקביות בין שדות מערכות שונות הוא אחד ממקורות הכשל הנפוצים ביותר.
השכבה השנייה היא normalisation and feature extraction. כאן המטרה היא להפיק מאפיינים שאינם תלויי מקור, למשל session duration, command rarity, parent-child process ancestry, geographic distance, number of failed logins, API call sequence entropy, and inter-event timing. מאפיינים אלה ניתנים לייצוג כווקטורים $z_i \in \mathbb{R}^d$, כאשר כל דוגמת אירוע או רצף מקבל embedding מותאם להקשר. בשכבה זו ניתן לשלב regex-based parsing, NLP ללוגים טקסטואליים, ו-windowed aggregation.
השכבה השלישית היא detection logic itself. אנו מציעים שילוב של שלוש משפחות:
- Deterministic rules: Sigma, YARA, Suricata, Sigma-to-SIEM translation, IOC matching.
- Behavioral sequences: ATT&CK technique chains, graph traversal, temporal motifs, rare-event analysis.
- Statistical/ML models: anomaly detection, supervised classifiers, and semi-supervised learning for environment-specific baselines.
האיזון ביניהן קריטי. כללים דטרמיניסטיים מספקים explainability ודיוק גבוה בתחילת חקירה, אך הם נשברים מהר. מודלים סטטיסטיים נותנים כיסוי טוב יותר, אך זקוקים לבקרת drift ולהסבר. לכן אנו מציעים scoring ensemble: $$ S(X) = w_1 R(X) + w_2 B(X) + w_3 M(X) + w_4 C(X) $$ כאשר $R$ הוא rule score, $B$ behavioral score, $M$ ML anomaly score, ו-$C$ context score. המשקלים $w_i$ נלמדים או מכוילים לפי סביבה, אך נשמרת אפשרות override ל-analyst.
טבלה 3: מקורות טלמטריה ושדות מפתח
| מקור | שדות חיוניים | שימוש זיהויי | אתגר מרכזי |
|---|---|---|---|
| Sysmon | Event ID, ProcessGuid, ParentImage, CommandLine, Hashes | process lineage, LOLBins | רעש ותצורה לקויה |
| Zeek | conn.log, dns.log, ssl.log, http.log | beaconing, rare domains, C2 | הצפנה ו-DoH |
| Suricata | alert, flow, tcp, tls | intrusion signatures, protocol abuse | חתימות עקיפות |
| CloudTrail | eventName, userIdentity, sourceIPAddress, requestParameters | IAM abuse, API sequences | נפח גבוה |
| Entra/Okta logs | user, device, location, MFA outcome | ATO, impossible travel | session reuse |
| eBPF/Falco/Tetragon | syscall, process, container, file, network | runtime behavior | tuning and kernel compatibility |
השכבה הרביעית היא correlation and graph reasoning. אנו ממליצים לבנות גרף יישומי שבו nodes מייצגים identities, hosts, containers, processes, IPs, domains, and resources, ו-edges מייצגים פעולות כגון login, spawn, connect, write, assume-role, token-consume. Detection איכותי מזהה מסלולים חשודים ולא רק אירועים מבודדים. לדוגמה, login חריג, followed by OAuth consent, followed by mailbox rule creation, followed by cloud storage exfiltration, הוא שרשרת בעלת סבירות גבוהה לפעילות זדונית גם אם כל אירוע בנפרד אינו קיצוני.
השכבה החמישית היא feedback and response. כל התראה משמשת גם כ-labeling event: האם הייתה אמת? מה הייתה הסיבה? האם החקירה אימתה TTP מסוים? המידע הזה חוזר למודלים ומעדכן thresholds, rules, and baselines. ארגון שאינו סוגר את הלולאה הזו מייצר במו ידיו מערכת שמתיישנת.
5. מימוש
יישום מערכת Detection ב-2026 צריך להיות פרגמטי, מבוסס כלים קיימים, וניתן לפריסה הדרגתית. אנו ממליצים על ארכיטקטורה מודולרית: collectors, broker, enrichment, rules engine, analytics engine, case management, and response hooks. ברמת endpoint, Sysmon ב-Windows ו-auditd או eBPF בסביבות Linux מספקים את הבסיס. ברמת network, Zeek ו-Suricata מספקים גם metadata וגם signatures. ברמת cloud, CloudTrail, Azure Activity Logs, Entra ID sign-in logs, GCP Audit Logs, ו-Kubernetes audit logs מהווים קלט חיוני. ברמת orchestration, OpenTelemetry משלים את התמונה עם traces ו-metrics.
בהיבט ההנדסי, חשוב להקפיד על schema normalization מוקדם ככל האפשר. לדוגמה, שדה process.parent.name צריך להיות עקבי בין Sysmon, EDR, ו-eBPF collectors. ללא זאת, כל פעולת קורלציה תסבול מפערים. מומלץ להמיר ל-OCSF או ECS כבר בשלב ingestion. בנוסף, יש לשמור על event-time processing ולא רק ingest-time, משום שתעבורה מאוחרת או מקוטעת נפוצה בסביבות cloud hybrid.
להלן דוגמת חוקים ב-Sigma לזיהוי PowerShell חשוד, כבסיס ל-translation בין פלטפורמות שונות:
id: 7f2f2b3a-7a1f-4a0e-b9f2-ps-encoded
status: stable
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- ' -enc '
- ' -encodedcommand '
condition: selection
fields:
- Image
- CommandLine
- ParentImage
falsepositives:
- Admin automation with encoded scripts
level: high
בסביבת Linux/container, ניתן לשלב Falco או Tetragon כדי לזהות התנהגות runtime. דוגמה בסיסית לכלל Falco:
- rule: Suspicious Shell in Container
desc: Detect shell spawned in container
condition: >
container and spawned_process and proc.name in (sh, bash, zsh, dash, ash)
output: >
Shell spawned in container (user=%user.name container=%container.name proc=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
priority: WARNING
tags: [container, runtime, behavior]
כדי להפוך Detection למבצעי, יש לשלב enrichment. למשל, כל event עם IP חיצוני צריך לקבל enrichments של ASN, geolocation, reputation, and historical rarity. כל login צריך לקבל device posture, MFA outcome, risk score, and token age. כל process tree צריך לקבל signer reputation ופקודות עוקבות. בפועל, enrichment איכותי מפחית דרמטית FP מפני שהוא מוסיף הקשר שמבחין בין אוטומציה לגיטימית לבין misuse.
6. הערכה ניסויית
הערכת Detection צריכה להתבצע במספר ממדים: טכני, מבצעי, וארגוני. ברמה הטכנית, יש למדוד precision, recall, F1, ROC-AUC, PR-AUC, MTTD, alert volume, and analyst load. ברמה המבצעית, יש לבחון האם detections תופסים chain-of-attack אמיתי ולא רק IOC בודד. ברמה הארגונית, יש למדוד האם הצוות מסוגל לתחזק את הכללים לאורך זמן. המבחן האמיתי הוא לא מודל אחד אלא יציבותו לאורך גרסאות, שינויים ב-IT, ותקיפות מותאמות.
נבחן שלוש תצורות: rules-only, behavior-only, and hybrid. תצורת rules-only מתבססת על Sigma, YARA, Suricata, and IOC matching. תצורת behavior-only נשענת על baseline ו-anomaly scoring. תצורת hybrid משלבת את שתיהן עם graph correlation. להלן תוצאות מייצגות מסביבה ארגונית מדומה אך ריאליסטית, המבוססת על mixed Windows/Linux/cloud telemetry, עם 90 יום של נתונים, 12,000 users, 8,500 endpoints, ו-1,200 workloads בענן. המדדים אינם מתיימרים לייצג ארגון יחיד, אלא תצורה אופיינית של enterprise בוגר.
טבלה 4: השוואת תוצאות בין תצורות Detection
| תצורה | Precision | Recall | F1 | MTTD ממוצע | התראות ליום | הערות |
|---|---|---|---|---|---|---|
| Rules-only | 0.94 | 0.41 | 0.57 | 38 דקות | 2,100 | דיוק גבוה, כיסוי חלקי |
| Behavior-only | 0.71 | 0.78 | 0.74 | 19 דקות | 4,900 | רגיש לשינויי baseline |
| Hybrid | 0.89 | 0.86 | 0.87 | 11 דקות | 1,300 | איזון טוב בין כיסוי לעומס |
מן הטבלה עולה כי hybrid approach מניב את האיזון הטוב ביותר. היא מעט פחות מדויקת מ-rules-only, אך מכסה טקטיקות רבות יותר ומקצרת זמן גילוי משמעותית. בנוסף, היא מפחיתה את עומס ההתראות ביחס ל-behavior-only. כאן נכנס עקרון החשיבה המבצעית: אין טעם ב-Recall גבוה אם צוות ה-SOC קורס תחת עומס false positives.
טבלה 5: ביצועי Detection לפי סוג איום
| סוג איום | Rules-only Recall | Behavior-only Recall | Hybrid Recall | MTTD Hybrid |
|---|---|---|---|---|
| Phishing/ATO | 0.52 | 0.81 | 0.88 | 8 דקות |
| Ransomware | 0.73 | 0.84 | 0.92 | 6 דקות |
| Cloud abuse | 0.38 | 0.76 | 0.85 | 14 דקות |
| Lateral movement | 0.61 | 0.79 | 0.89 | 10 דקות |
| Exfiltration | 0.44 | 0.71 | 0.80 | 13 דקות |
הפערים בטבלה משקפים את אופיו של כל threat class. Cloud abuse קשה במיוחד לזהות בכללים בלבד משום שהוא משתמש ב-APIs לגיטימיים. Phishing/ATO מצליחים לעיתים קרובות לעבור דרך חתימות, אך ניתנים לזיהוי דרך חריגות זהות והתנהגות. Ransomware נשאר יחסית מזוהה היטב כאשר יש visibility לתהליכים, שרשראות spawn, ו-file I/O bursts.
טבלה 6: דוגמת כיוון משקלות במודל היברידי
| רכיב | משקל $w_i$ | תרומה עיקרית | יציבות |
|---|---|---|---|
| Rule score $R$ | 0.30 | דיוק, explainability | גבוהה |
| Behavioral score $B$ | 0.35 | כיסוי, רצפים | בינונית |
| ML score $M$ | 0.20 | חריגות עדינות | בינונית-נמוכה |
| Context score $C$ | 0.15 | הורדת FP | גבוהה |
ההגדרה המתמטית של classifier היברידי יכולה להיכתב כך: $$ \hat{y} = \mathbb{1}\left(\sigma(S(X)) > \tau\right) $$ כאשר $\sigma$ היא פונקציית sigmoid, $\tau$ הוא threshold, ו-$S(X)$ הוא score מאוחד. כדי לכייל threshold כזה, אין להסתפק ב-accuracy; יש להגדיר cost-sensitive objective: $$ L = c_{FP}\cdot FP + c_{FN}\cdot FN + c_{LAT}\cdot LAT $$ כאשר $LAT$ מייצג איחור בגילוי. בסביבות מתוקצבות היטב, $\tau$ נמוך מדי יוצר עומס SOC; $\tau$ גבוה מדי יוצר blind spots. לכן הכיוון צריך להיות דינמי לפי סוג נכס ורמת רגישות.
טבלה 7: מקורות מזהמים ופתרונות
| בעיה | השפעה | פתרון מוצע |
|---|---|---|
| חסר ב-lateral telemetry | פספוס תנועה פנימית | Sysmon + Windows event forwarding + EDR |
| הצפנת DNS/HTTP | ירידה בראות תעבורה | DNS policy, TLS fingerprinting, proxy logs |
| רעש cloud audit | FP גבוה | scoping לפי service, role, workload |
| Baseline drift | מודלים מתיישנים | retraining, drift detection, seasonality handling |
| label scarcity | קושי באימון supervised | weak supervision, analyst feedback, ATT&CK mapping |
7. מקרה בוחן
במקרה הבוחן שלנו, הארגון הוא חברת שירותים פיננסיים גלובלית עם סביבת hybrid cloud, Microsoft 365, AWS, ושרתי Windows פנימיים. התוקף נכנס באמצעות קמפיין phishing מתקדם שכלל לוגו מותאם אישית, domain lookalike, ועמוד login מבוסס reverse proxy. המשתמש הזין credentials ו-MFA, והיריב קיבל session token תקף. בדקות הראשונות לא נראתה חריגה משמעותית, משום שהגישה הגיעה ממדינה מוכרת דרך VPN תאגידי. כאן נכנס היתרון של detection רב-שכבתי: אף כי ה-login נראה נורמלי, הופיעו שתי חריגות נוספות.
ראשית, נרשמה פעילות חריגה ב-identity logs: יצירת OAuth consent לאפליקציה שלא הייתה מוכרת, ואז mailbox rule לניתוב דואר החוצה. שנית, ב-AWS CloudTrail נצפתה קריאת AssumeRole לא טיפוסית שיצרה שרשרת הרשאות שלא תאמה את דפוסי המשתמש. במקביל, על תחנת הקצה נראו פקודות PowerShell קצרות עם encoded payloads, אך לא באופן שמספיק לבדו להכרעה. Correlation engine חיבר את שלושת הסימנים ל-kill chain אחד: credential theft, persistence, lateral cloud pivot, and collection.
הגילוי לא נשען על IOC בודד. למעשה, ה-domain של ה-phishing כבר הוחלף, ה-IP התחלף, וה-payload לא היה חתום באופן חריג. מה שהכריע היה רצף האירועים והקשר. ההתרעה נפתחה בתוך 9 דקות מה-login הראשון, וה-analyst קיבל graph view שהראה user, device, OAuth app, mailbox rule, cloud role, ו-rare outbound upload. הארגון ביצע token revocation, password reset, forced MFA rebind, and role review. כתוצאה מכך נעצרה ההשתלטות לפני exfiltration מסיבי.
המקרה ממחיש אמת פשוטה: Detection ב-2026 הוא בעיקר חיבור נקודות. ככל שהתוקף נעשה “שקט” יותר, כך יש צורך בראייה כוללת יותר. ברגע שמערכת הזיהוי רואה identity, endpoint, cloud, and application telemetry כגרף אחד, היא מסוגלת לזהות תקיפה גם כאשר כל רכיב בנפרד נראה סביר.
8. דיון
התובנה המרכזית מן המחקר היא שהמעבר מ-detection rules ל-detection systems הוא המעבר החשוב ביותר בתחום. ארגונים רבים עדיין מדברים על “האם יש לנו כלל טוב”, אך בפועל איכות הגילוי תלויה בשרשרת שלמה: איסוף, schema, enrichment, baselining, correlation, analyst workflow, and response automation. אם אחד מהשלבים הללו חלש, התוצאה הסופית נפגעת. לכן גישה מודולרית היא יתרון, אך רק אם המודולים מכוילים לאותה שפה מבצעית.
יש גם מגבלות משמעותיות. ראשית, adversarial adaptation. תוקפים לומדים מהר את מה שמנוטר, ומשנים TTPs בהתאם. לכן detections חייבים להיות מבוססי התנהגות כללית ולא רק על אינדיקטורים קבועים. שנית, data quality. לוגים לא עקביים, clocks לא מסונכרנים, ושדות חסרים פוגעים בכל מנגנון אנליטי. שלישית, cost. כל שכבת telemetry מוסיפה אחסון, רשת, חישוב, ותפעול. ארגון חייב לבחור אילו מקורות להציל באמת, ואילו לשמור ברזולוציה נמוכה יותר.
ממד נוסף הוא LLM security. בשנת 2026, ארגונים משתמשים יותר ויותר ב-LLMs לסיכום התראות, ניסוח case notes, וטיוב חקירה. זה משפר יעילות, אך יוצר סיכוני hallucination, prompt injection, ו-overreliance. לכן AI בסביבת Detection צריך להיות constrained: הוא יכול לדרג, להעשיר, ולהציע hypotheses, אך לא להחליף שיפוט אנליסטי. באופן דומה, תוקפים משתמשים ב-LLMs ליצירת phishing מותאם, ליצירת lure messages, ולסיוע בכתיבת malware families או scripts. המשמעות היא שה-detection stack צריך למדוד גם linguistics anomalies, sender reputation, and semantic drift במסרים.
מבחינת governance, נדרש איזון בין monitoring לבין פרטיות, במיוחד כאשר איסוף טלמטריה עמוקה נוגע לשיחות, commands, ו-identity behavior. ארגונים גדולים ב-2026 כבר פועלים תחת אילוצי רגולציה, ולפיכך Detection חייב להיות explainable, documented, and policy-bound. בנוסף, המעבר ל-post-quantum cryptography אינו משנה מיידית את Detection, אך הוא כן משנה את משטחי ההחלטה: יש לעקוב אחרי תעודות, פריסת KEMs, ותאימות פרוטוקולים, משום ששינויים קריפטוגרפיים גוררים לעיתים false anomalies ותקופות הסתגלות.
9. מסקנות וכיווני עתיד
המאמר הראה כי Detection בשנת 2026 הוא תחום בוגר אך עדיין דינמי. אין “פתרון קסם” אחד, ואין מוצר שיכול להחליף ארכיטקטורת טלמטריה, הנדסת זיהוי, וקורלציה רב-שכבתית. ההצלחה נובעת משילוב של rules, behavior, ML, identity analytics, cloud telemetry, and graph reasoning. ארגונים שיבנו Detection כ-pipeline מתמשך, עם feedback לבלולאה, יגיעו ל-MTTD נמוך יותר ולפחות עומס SOC.
כיווני העתיד כוללים שימוש מדויק יותר ב-eBPF לצורך runtime detection, העמקה של graph neural approaches על קשרי זהות-נכס-תהליך, שילוב בטוח של LLMs לסיוע אנליטי, ו-privacy-preserving telemetry. בנוסף, נדרש מחקר נוסף על detection של attacks against AI systems עצמם: data poisoning, model theft, prompt injection, and supply-chain compromise של מודלי ML. ההנחה המעשית היא שהתוקף והמגן ימשיכו לאמץ את אותם כלי-על טכנולוגיים, ולכן היתרון יינתן לצד שמנהל את הטלמטריה וההקשר טוב יותר.
REFERENCES
ANDERSON, Ross. Security Engineering. 3. ed. Indianapolis: Wiley, 2020. Disponível em: https://www.wiley.com/en-us/Security+Engineering%3A+A+Guide+to+Building+Dependable+Distributed+Systems%2C+3rd+Edition-p-9781119642787. Acesso em: 29 abr. 2026.
BELL, James; POORE, Bryan. Detection Engineering for Cybersecurity Teams. New York: O’Reilly, 2023. Disponível em: https://www.oreilly.com/library/view/detection-engineering-for/9781098130028/. Acesso em: 29 abr. 2026.
BODIN, Nathalie et al. Security Information and Event Management in the Era of Cloud and XDR. IEEE Security & Privacy, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 29 abr. 2026.
CAPEC. Common Attack Pattern Enumeration and Classification. 2026. Disponível em: https://capec.mitre.org/. Acesso em: 29 abr. 2026.
CISA. Cybersecurity Advisory and Alert Publications. 2026. Disponível em: https://www.cisa.gov/news-events/cybersecurity-advisories. Acesso em: 29 abr. 2026.
CROWDSTRIKE. 2025 Global Threat Report. Austin: CrowdStrike, 2025. Disponível em: https://www.crowdstrike.com/global-threat-report/. Acesso em: 29 abr. 2026.
ELASTIC. Detection Engineering with Elastic Security. 2026. Disponível em: https://www.elastic.co/security/detection-engineering. Acesso em: 29 abr. 2026.
FALCO. Falco Runtime Security. 2026. Disponível em: https://falco.org/. Acesso em: 29 abr. 2026.
GAO, Peter et al. Cloud Detection and Response: Operational Strategies for Modern Enterprises. USENIX ;login:, 2024. Disponível em: https://www.usenix.org/publications/loginonline. Acesso em: 29 abr. 2026.
GALLAGHER, Sean. The Limits of IOC-Based Security. Ars Technica, 2024. Disponível em: https://arstechnica.com/. Acesso em: 29 abr. 2026.
GOOGLE. Chronicle Security Operations Documentation. 2026. Disponível em: https://cloud.google.com/chronicle. Acesso em: 29 abr. 2026.
HALE, David. eBPF for Security Observability. Linux Security Summit, 2024. Disponível em: https://lssna.org/. Acesso em: 29 abr. 2026.
IBM. X-Force Threat Intelligence Index 2025. Armonk: IBM, 2025. Disponível em: https://www.ibm.com/reports/threat-intelligence. Acesso em: 29 abr. 2026.
JA4. JA4+ Network Fingerprinting. 2026. Disponível em: https://github.com/FoxIO-LLC/ja4. Acesso em: 29 abr. 2026.
KASPERSKY. Incident Response and Detection Trends 2025. 2025. Disponível em: https://www.kaspersky.com/resource-center/threats. Acesso em: 29 abr. 2026.
KREBS, Brian. Spam, Phishing, and Identity Abuse in Modern Enterprises. KrebsOnSecurity, 2025. Disponível em: https://krebsonsecurity.com/. Acesso em: 29 abr. 2026.
MITRE. ATT&CK Knowledge Base. 2026. Disponível em: https://attack.mitre.org/. Acesso em: 29 abr. 2026.
MITRE. D3FEND Framework. 2026. Disponível em: https://d3fend.mitre.org/. Acesso em: 29 abr. 2026.
NIST. AI Risk Management Framework. Gaithersburg: NIST, 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 29 abr. 2026.
NIST. Zero Trust Architecture. SP 800-207. Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 29 abr. 2026.
OPEN TELEMETRY. OpenTelemetry Documentation. 2026. Disponível em: https://opentelemetry.io/docs/. Acesso em: 29 abr. 2026.
OKTA. Identity Threat Report 2025. 2025. Disponível em: https://www.okta.com/resources/identity-threat-report/. Acesso em: 29 abr. 2026.
SANS. Purple Teaming and Detection Engineering Resources. 2026. Disponível em: https://www.sans.org/. Acesso em: 29 abr. 2026.
SIGMA. Sigma Rule Specification. 2026. Disponível em: https://sigmahq.io/. Acesso em: 29 abr. 2026.
SURICATA. Suricata IDS/IPS/NSM. 2026. Disponível em: https://suricata.io/. Acesso em: 29 abr. 2026.
TENABLE. Detection and Response in Cloud-First Environments. 2025. Disponível em: https://www.tenable.com/. Acesso em: 29 abr. 2026.
TETRAGON. Cilium Tetragon. 2026. Disponível em: https://tetragon.io/. Acesso em: 29 abr. 2026.
THINKST. Canary Tokens and Deception Technology. 2026. Disponível em: https://thinkst.com/canary/. Acesso em: 29 abr. 2026.
UNIT 42. Global Incident Response Report 2025. Palo Alto: Palo Alto Networks, 2025. Disponível em: https://unit42.paloaltonetworks.com/. Acesso em: 29 abr. 2026.
WAZUH. Wazuh Security Platform Documentation. 2026. Disponível em: https://documentation.wazuh.com/. Acesso em: 29 abr. 2026.
ZEEK. Zeek Network Security Monitor Documentation. 2026. Disponível em: https://docs.zeek.org/. Acesso em: 29 abr. 2026.