,

האנטי-וירוס מת. יחי המלך החדש: למה EDR הוא לא “עוד מוצר אבטחה” אלא העיניים שלכם ברשת

תמונת פרופיל של OSHRI.PINHAS
האנטי-וירוס מת. יחי המלך החדש: למה EDR הוא לא “עוד מוצר אבטחה” אלא העיניים שלכם ברשת

זוכרים את הימים שבהם היה לנו אייקון ירוק קטן בשורת המשימות למטה, שהבטיח לנו שאנחנו מוגנים? הייתם קונים רישיון ל-NOD32 או Norton, מעדכנים “חתימות” פעם ביום, והולכים לישון בשקט. היום, פתרונות אבטחה מתקדמים כמו EDR כבר מחליפים את מה שהכרנו פעם. ובכן, הימים האלו נגמרו.

בעולם הסייבר של 2026, להסתמך על אנטי-וירוס קלאסי (Legacy AV) זה כמו לנסות לעצור טיל מונחה עם רשת נגד יתושים. התוקפים השתכללו, הם כבר לא שולחים קבצים עם חתימות מוכרות. הם משתמשים ב-Fileless Attacks, הם מריצים סקריפטים שחיים בזיכרון (RAM), והם משתמשים בכלים לגיטימיים של ווינדוס כדי לתקוף אתכם.

כאן נכנס לתמונה ה-EDR (Endpoint Detection and Response). בפוסט הזה אני רוצה לפתוח את הקופסה השחורה הזו. להסביר למה הוא הרבה יותר מאנטי-וירוס, איך הוא לומד אתכם, למה הוא לפעמים “משתגע” וחוסם דברים לגיטימיים (כן, גם לי זה קרה עם JumpCloud), ולמה בלי לחבר אותו ל-SIEM – אתם רואים רק חצי תמונה.

EDR vs Antivirus: למה ארגונים חייבים הגנה מבוססת התנהגות ב-2026?
EDR vs Antivirus: למה ארגונים חייבים הגנה מבוססת התנהגות ב-2026?

רגע, מה ההבדל בין EDR לאנטי-וירוס?

כדי להבין EDR, צריך להבין מה היה לנו קודם. אנטי-וירוס מסורתי עובד כמו שומר במועדון שיש לו רשימה שחורה של אנשים שאסור להכניס (“חתימות”). מגיע קובץ? הוא בודק ברשימה. מופיע ברשימה? נחסם. לא מופיע? כנס, תרגיש בבית. הבעיה? אם לתוקף יש “תחפושת” חדשה שהשומר לא מכיר (Zero Day), הוא נכנס חופשי.

EDR הוא שומר מסוג אחר. הוא לא מסתכל רק על “מי אתה” (החתימה של הקובץ), אלא על “מה אתה עושה” (Behavioral Analysis). ה-EDR מכיל בתוכו את יכולות האנטי-וירוס הישן, אבל זה רק קצה הקרחון. המוח האמיתי שלו עוסק בניתוח התנהגות.

edr יושב ברקע ושואל שאלות חשדניות כל הזמן:

  • “למה קובץ Word מנסה להריץ סקריפט PowerShell?”
  • “למה התהליך הזה מנסה לגשת לזיכרון של תהליך אחר (Process Injection)?”
  • “למה הדפדפן מנסה לשנות מפתח ב-Registry שקשור לאתחול המחשב?”

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

כשה-EDR עובד קשה מדי: סיפור מהשטח על SentinelOne ו-JumpCloud

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

קחו דוגמה מהחיים האמיתיים אצלי: אני עובד עם SentinelOne (אחד ממוצרי ה-EDR המובילים בשוק) ועם JumpCloud לניהול המחשבים. יום אחד ניסיתי להתקין סוכן של JumpCloud על מחשב שכבר היה מותקן עליו SentinelOne. בום. החסימה הייתה מיידית. ה-SentinelOne זיהה את ההתקנה, עצר אותה, וזרק אותה לבידוד (Quarantine).

למה? כי אם תחשבו על זה, מה JumpCloud עושה?

  1. הוא יוצר משתמשים אדמיניסטרטיביים במערכת.
  2. הוא משנה הגדרות ליבה (Core OS).
  3. הוא שולח פקודות מרחוק (Remote Execution).
  4. הוא נוגע ברג’יסטרי עמוק.

מבחינת ה-EDR, ההתנהגות הזו זהה ב-100% להתנהגות של רוגלה (Rootkit) או סוס טרויאני מתוחכם שמנסה להשתלט על המחשב. ה-EDR עשה את העבודה שלו מצוין – הוא זיהה שינוי עמוק במערכת וחסם אותו.

אמנות ה-Fine Tuning: לא ללחוץ סתם על “Allow”

כאן נמדד המקצועיות של מנהל ה-IT או ה-SOC. כשקופצת התראה כזו, האינסטינקט הראשוני הוא להתעצבן ולהגיד “נו, המערכת הזאת סתם חוסמת לי עבודה”, וללחוץ על Unquarantine & Allow.

אל תעשו את זה אוטומטית. התפקיד שלנו הוא לחקור. אנחנו צריכים להיכנס ללוגים, לראות בדיוק איזה תהליך נחסם, ולוודא שזה אכן ה-Installer הלגיטימי של JumpCloud (לפי ה-Hash של הקובץ או ה-Certificate החתום). רק אחרי שווידאנו שזה False Positive, אנחנו מבצעים Fine Tuning (כיוונון עדין): אנחנו יוצרים חוק החרגה (Exclusion) שאומר ל-EDR: “אם אתה רואה את התהליך הזה, עם החתימה הזאת, בתיקייה הזאת – תן לו לרוץ. אני מכיר אותו.”

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

החתיכה החסרה: למה EDR לבד זה לא מספיק?

אז יש לנו EDR חכם על כל מחשב. אנחנו מוגנים, נכון? בערך. ה-EDR הוא “חייל בודד”. הוא רואה מה קורה על המחשב הספציפי של המזכירה, או על השרת הספציפי בחדר שרתים. אבל מה אם התקיפה היא רוחבית? מה אם התוקף ניסה להיכנס ל-VPN (שמנוהל ב-Firewall), ואז שלח מייל פישינג (שעבר ב-Office 365), ואז ניסה להריץ פקודה בשרת?

ה-EDR רואה רק את החלק האחרון. הוא לא רואה את הסיפור המלא. כאן אנחנו חייבים מוצר משלים: SIEM (Security Information and Event Management).

מלהיות “מגיבים” ללהיות “ציידים” (Proactive Hunting)

מערכת ה-SIEM היא ה”מוח” המרכזי. אנחנו מחברים אליה את ה-EDR, אבל גם את ה-Firewall, את ה-IdP (כמו Okta/JumpCloud), ואת שרתי הדואר. כל המידע הזה זורם למקום אחד.

היום, בעזרת כלים כמו Elasticsearch (Kibana) או Graylog, אנחנו יכולים לבנות דשבורדים ויזואליים שמראים לנו את כל התמונה:

  1. קורלציה (Correlation): המערכת יכולה להגיד לי “היי, ראיתי 5 ניסיונות כניסה כושלים ב-JumpCloud (שזה לגיטימי אולי), אבל דקה אחרי זה ה-EDR זיהה הרצת סקריפט חשודה באותו משתמש.” – זה כבר אירוע חירום.
  2. פרו-אקטיביות: אם ה-EDR פספס משהו (וזה קורה), או אם הוא רק “חשד” אבל לא חסם, ה-SIEM מאפשר לי לחפש את האיומים האלו באופן יזום (Threat Hunting). אני יכול לשאול את המערכת: “תראה לי את כל המחשבים שבהם הורץ סקריפט PowerShell בשעה 2 בלילה”.

לסיכום: זה לא “שגר ושכח”

הטמעת EDR היא צעד קריטי, אבל היא דורשת שינוי תפיסה. זה לא מוצר שמתקינים ושוכחים ממנו. זו מערכת חיה, לומדת ובועטת. היא דורשת מאיתנו להיות קשובים למשתמשים (שפתאום נחסם להם ה-Zoom), להיות חשדניים כלפי התראות, ולהבין לעומק איך מערכת ההפעלה עובדת (Registry, Memory, Services).

השילוב המנצח הוא לא רק הכלי הכי יקר, אלא הארכיטקטורה: EDR חזק בקצה + SIEM חכם במרכז + מנהל IT שמבין שכל חסימה היא הזמנה לחקירה.

תפריט נגישות