המסך ב-SentinelOne Management Console נצבע באדום. יש התראה חדשה. הלב מחסיר פעימה לשנייה. האם זו מתקפת כופרה? האם מישהו פרץ לרשת? או שזה שוב המנהל חשבונות שמנסה להתקין את התוכנה ההזויה ההיא למס הכנסה?
הדילמה של איש ה-SOC או מנהל ה-IT היא יומיומית: אם אני אחסום תוכנה לגיטימית – אני עוצר את העבודה של הארגון והטלפון שלי יתחיל לצלצל בעצבים. אם אני אאשר תוכנה זדונית בטעות (כי חשבתי שזה False Positive) – אני פותח דלת אחורית לתוקף.
אז איך יודעים? הנה המתודולוגיה המלאה שלי לחקירת אירועים ב-SentinelOne. אני לא לוחץ על “Mark as Threat” וגם לא על “Mark as Benign” עד שאני לא עובר את שבעת מדורי הגיהנום של הבדיקה.
שלב 1: מבחן הכמות (Scope Analysis)
הדבר הראשון שאני עושה כשאני נכנס ללשונית Incidents, לפני שאני בכלל מסתכל על שם הקובץ, זה להסתכל על ה-Scope.
השאלה הראשונה: האם זה קורה רק במחשב אחד, או שזה מתפשט כמו אש בשדה קוצים?
- אם זה קורה ב-50 מחשבים בו זמנית: רוב הסיכויים שמדובר בעדכון תוכנה רוחבי (למשל, עדכון של Chrome או כלי פנימי של הארגון) שהמנוע ההתנהגותי (Behavioral AI) זיהה כחשוד. במקרה כזה, החשד ל-False Positive עולה, אבל עדיין דורש בדיקה.
- אם זה קורה במחשב בודד: כאן נדלקת נורה אדומה בוהקת. למה דווקא דני מהשיווק חוטף התראה? אם זו תוכנה לגיטימית שכולם משתמשים בה, למה היא צועקת רק אצלו?
- ההנחה הראשונית שלי במקרה כזה: זה לא False Positive עד שהוכח אחרת.
שלב 2: ניתוח כירורגי של האירוע (Threat Indicators)
עכשיו אני צולל פנימה לתוך האירוע. אני לא מסתפק בכותרת “Malware”. אני בודק את הפרטים הקטנים:
- נתיב הקובץ (File Path): איפה הקובץ יושב? האם זה ב-
C:\Program Files\Adobe(נראה לגיטימי, אולי DLL לא חתום) או שזה ב-C:\Users\User\AppData\Local\Temp\Invoice_Run.exe(חשוד מאוד)? נתיבים זמניים הם קרקע פורייה לנוזקות. - סגנון ההתקפה (Threat Indicators): על מה SentinelOne צעק?
- האם זה זיהוי סטטי (Static AI)? כלומר, הקובץ עצמו נראה חשוד.
- האם זה זיהוי דינמי (Lateral Movement / Credential Dumping)? אם אני רואה התראה על ניסיון לגניבת סיסמאות או תנועה רוחבית – אני לא לוקח צ’אנסים. זה כמעט אף פעם לא False Positive תמים.
שלב 3: בדיקת המוניטין (The “Old School” Check)
בתוך הקונסולה של SentinelOne (וברוב מערכות ה-EDR), יש כפתור קטן שלפעמים מזלזלים בו: Fetch Threat Intelligence (או בדיקת Hash מול VirusTotal).
נכון, אנחנו בעידן ה-AI, והסתמכות על חתימות (Hashes) נחשבת למיושנת. אבל, זו אינדיקציה מעולה לשלילת חשד. אני לוחץ על הכפתור ושולח את ה-Hash לבדיקה מול עשרות מנועי אנטי-וירוס אחרים.
- תוצאה 0/70: אף אחד לא מכיר את הקובץ הזה. זה לא אומר שזה נקי, זה אומר שזה חדש (וזה מחשיד).
- תוצאה 50/70 (כולל מיקרוסופט וקספרסקי): אוקיי, כולם מסכימים שזה וירוס. נגמר הסיפור. True Positive.
- תוצאה ירוקה (Clean): אם הקובץ מוכר וחתום דיגיטלית על ידי חברה מוכרת (כמו Google או Oracle), זה מחזק את ההשערה שמדובר ב-False Positive.
שלב 4: החקירה האנושית (החלק שרוב אנשי ה-IT מדלגים עליו)
לפני שאני ממשיך בטכנולוגיה, אני מרים טלפון למשתמש. הלוגים מספרים רק חצי סיפור.
אני שואל אותו שאלות מכוונות (בלי להלחיץ):
- “הפעלת משהו עכשיו וקיבלת הודעת חסימה?” – אני רוצה לוודא התאמה בין זמן ההתראה לפעולת המשתמש. אם הוא אומר “אני בכלל בהפסקת צהריים והמחשב נעול”, ויש התראה על הרצת קובץ – יש לנו אירוע אמת.
- “ניסית להפעיל את זה כמה פעמים?” – ב-SentinelOne אני אראה לפעמים 5-6 התראות רצופות באותה דקה. זה בדרך כלל משתמש מתוסכל שמקליק שוב ושוב על הקובץ החסום.
- “מה השתנה?” – השתמשת בתוכנה הזו אתמול? אם כן, למה היום היא קפצה? האם הורדת עדכון גרסה?
- “מאיפה הורדת את זה?” – זו שאלת המיליון דולר.
- “מהאתר הרשמי של Autodesk” – מרגיע.
- “שלחו לי קישור בטלגרם להורדת תוכנה בחינם” – BOOM. זה לא False Positive, זה משתמש שהוריד נוזקה במסווה של תוכנה לגיטימית.
שלב 5: שחזור בסביבה סטרילית (The Sandbox Test)
אם המשתמש טוען שזה קובץ לגיטימי מהאתר הרשמי, אני לא סומך עליו בעיניים עצומות (“סמוך אבל בדוק”).
אני לוקח מחשב בדיקה (Test Machine) שיש עליו SentinelOne, מבודד מהרשת הארגונית, ומנסה לשחזר את הפעולה:
- נכנס לאותו אתר ומוריד את הקובץ בעצמי.
- מריץ אותו.
- האם ה-S1 צועק גם אצלי?
- אם כן: ייתכן שהגרסה החדשה של התוכנה מכילה רכיב שה-AI לא אוהב.
- אם לא (הקובץ רץ חלק אצלי): למה אצל המשתמש זה נחסם? אולי הקובץ אצלו “נגוע”? אולי הוא הוריד משרת מתחזה (Phishing)?
בשלב הזה אני מבקש מהמשתמש (או מנסה בעצמי) להוריד גרסה עדכנית יותר של הקובץ. לפעמים המפתחים כבר תיקנו את החתימה הדיגיטלית בגרסה החדשה, וזה פותר את הבעיה בלי שאצטרך לעשות Exclude.
שלב 6: חובת ההתייעצות (CISO Approval)
יש מקרים אפורים. נניח שמדובר בקובץ שרץ רק אצל מפתח אחד, הוא הורד מ-GitHub, והוא מבצע פעולות שמזכירות מאוד נוזקה (כמו הזרקת קוד לתהליכים אחרים). המשתמש נשבע שהוא צריך את זה לעבודה.
כאן אני עוצר. אני לא לוקח את האחריות לבד. אם זה נראה כמו התקפה רגישה, או קובץ שיכול לגרום נזק רוחבי, אני פונה ל-CISO (מנהל אבטחת המידע). אני מציג לו את הממצאים: “שמע, זה נראה חשוד, אבל המשתמש מתעקש. ה-VirusTotal נקי, אבל ההתנהגות אגרסיבית. לאשר?” רק אחרי אישור שלו אני מתקדם.
שלב 7: הביצוע הטכני (Mark as False Positive)
רק אחרי שעברתי את כל השלבים האלו, ושוכנעתי ב-100% שהקובץ בטוח, אני מבצע את הפעולה בקונסולה:
- נכנס לאירוע.
- בוחר ב-Analyst Verdict: False Positive.
- חשוב מאוד: בוחר את ה-Scope של ה-Exclusion. האם לאשר את הקובץ (Hash) הזה לכל הארגון (Global)? או רק לקבוצת המחשבים של המפתחים (Group)? תמיד עדיף לצמצם הרשאות (Least Privilege).
- מחכה כמה דקות שהמדיניות תתעדכן בתחנות הקצה (אפשר לראות ב-Agent Logs שהפוליסי התקבל).
- מודיע למשתמש: “שחררתי, תנסה שוב עכשיו”.
סיכום: סבלנות היא כלי אבטחה
תהליך של בדיקת False Positive יכול לקחת 10 דקות, ולפעמים גם שעה. משתמשים ילחצו עליכם, מנהלים יבקשו “רק לשחרר את זה רגע”. אל תיכנעו. ההבדל בין איש System רגיל לבין מומחה אבטחה הוא היכולת להגיד: “אני לא משחרר עד שאני לא בטוח שזה לא יהרוס לנו את הארגון.”
המתודולוגיה הזו – מהבדיקה הגלובלית ועד התשאול האישי – היא מה שמפריד בין לילה שקט לבין אירוע סייבר שנגמר בחדשות.
איך אתם מנהלים את ה-FP שלכם? יש לכם טיפ נוסף לבדיקה? שתפו אותי בתגובות.