סייבר ואבטחת מידע · soc-operations

False Positive ב-SOC: איך מזהים, מתעדים ומצמצמים

מאת תאיר מלכא 6 דק׳ קריאהפורסם: 5 באוגוסט 2026

המחשה חזותית מקצועית בנושא False Positive ב-SOC בתחום SOC ותפעול

תשובה מהירה

False Positive ב-SOC הוא מקרה שבו התראה נוצרה בגלל לוגיקה שגויה או נתונים לא מדויקים, אף שלא התקיימה ההתנהגות המסוכנת שהחוק התכוון לזהות. כדי לסגור נכון צריך להוכיח את הסיבה, להבדיל מפעילות חשודה אך מאושרת, לתעד את ה-Root Cause ולהעביר משוב שמצמצם התראות דומות בלי ליצור Blind Spot.

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

השלב הראשון הוא להשתמש בשפה מדויקת. Microsoft Sentinel ו-Splunk מבחינים בין True Positive, Benign Positive ו-False Positive. פעילות של סורק מורשה עשויה להיות Benign Positive — החוק זיהה נכון התנהגות חשודה, אך היא צפויה. לעומת זאת, אם החוק פירש שדה שגוי או שהמקור שלח נתון לא מדויק, מדובר ב-False Positive.

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

מהו False Positive — ומה הוא לא

False Positive נוצר כאשר המנגנון קובע שהתקיימה התנהגות מסוכנת, אך בפועל תנאי היסוד אינם נכונים. דוגמה: חוק מזהה תהליך בשם powershell.exe כהרצה חשודה, אך הנתון הגיע משדה שמתאר קובץ יעד ולא תהליך שרץ. דוגמה אחרת היא מיקום גאוגרפי שגוי בגלל מאגר IP לא מעודכן.

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

גם “לא מצאתי הוכחה לתקיפה” אינו False Positive. ייתכן שהאירוע לא מוכרע, שהטלמטריה חסרה או שהפעילות נעצרה לפני שנוצרו סימנים נוספים.

אילו ראיות נדרשות לסגירה

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

ראיה טובה מאפשרת לאדם אחר להגיע לאותה מסקנה. משפט כמו “ה-IP מוכר” חלש; משפט כמו “הכתובת שייכת לסורק Tenable הארגוני לפי CMDB, הסריקה בוצעה בחלון המאושר CR-4821 והיעדים תואמים לרשימה” הוא בר-ביקורת.

כאשר סוגרים, בחרו סיווג מדויק והוסיפו Comment. Microsoft Sentinel מחייב Classification בסגירת Incident ומציע בין היתר False Positive עקב לוגיקה שגויה, False Positive עקב נתונים לא מדויקים ו-Benign Positive.

Root Cause של התראות שווא

אפשר לחלק את הסיבות לחמש משפחות: לוגיקה רחבה מדי, נתונים לא איכותיים, נרמול שגוי, חוסר הקשר ארגוני ושינוי בסביבה. חוק שמחפש כלי לגיטימי ללא התנהגות נלווית יהיה רחב; כתובות IP שעברו NAT עלולות ליצור שיוך משתמש שגוי; שדה process.name שמופה מ-source לא מתאים יוצר נרמול בעייתי; וחוק שלא מכיר חשבון שירות יראה פעילות אוטומטית כחריגה.

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

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

תיעוד ומשוב ל-Detection Engineering

כרטיס משוב צריך לכלול: שם החוק וגרסה, דוגמת אירוע, סיווג, Root Cause, שכיחות, משתמשים/נכסים מושפעים, סיכון בהחרגה והצעה לשינוי. Detection Engineer צריך להבין גם מה לא לשנות. אם חוק תפס פעילות אדמין לגיטימית, החרגת כל קבוצת האדמינים עלולה ליצור Blind Spot; ייתכן שעדיף להגביל לחשבון, כלי חתום, נתיב, מכשיר ניהול וחלון זמן.

Microsoft Sentinel מאפשר לטפל בחלק מה-False Positives באמצעות Automation Rules, ששומרות Audit Trail ויכולות להיות מוגבלות בזמן, או באמצעות שינוי Analytics Rule, שמאפשר ביטויים מתקדמים ו-Watchlists. Elastic מאפשר Rule Exceptions עבור תהליכים או פעילות רשת אמינים. בכל מקרה, Exception צריך בעלים, סיבה, תאריך בדיקה ותוקף.

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

מדידת שיפור לאורך זמן

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

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

קבעו מחזור Review: שבועי לחוקים רועשים, חודשי לכללים מרכזיים ורבעוני ל-Exceptions. Exceptions ללא בעלים או תוקף הם חוב אבטחתי.

שלושה מקרים לדוגמה

מקרה 1 — פעילות אדמין: PsExec הופעל משרת ניהול מאושר על ידי חשבון Tier 0 במסגרת שינוי מתועד. ההתנהגות חשודה מטבעה אך מאושרת; סיווג מתאים עשוי להיות Benign Positive. החרגה צריכה להיות צרה ולהתבסס על מקור, חשבון, חתימה וחלון.

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

מקרה 3 — כלי לגיטימי: חוק מתריע על certutil.exe בכל שימוש. צוות פיתוח משתמש בו להמרת קידוד מקומית ללא חיבור רשת. במקום להחריג את הכלי, משנים את החוק כך שיחפש שימוש עם הורדה, כתובת URL, נתיב חריג או תהליך אב חשוד.

Checklist מעשי

סיווגתי False Positive לעומת Benign Positive.
מצאתי ראיה חיובית להסבר ולא רק היעדר ראיות.
זיהיתי Root Cause.
תיעדתי חוק, גרסה ודוגמת אירוע.
הערכתי את סיכון ההחרגה.
הגדרתי Owner ותוקף ל-Exception.
בדקתי את השינוי מול אירועים היסטוריים.

טעויות נפוצות

להחריג משתמש או כלי שלם במקום תנאי מצומצם.
לסגור את כל המקרים הלא ברורים כ-False Positive.
לשנות חוק ללא Backtest.
לא להבדיל בין בעיית נתונים לבעיית לוגיקה.
למדוד הצלחה רק לפי ירידה בכמות ההתראות.

סיכום ו-CTA

בחרו חוק אחד שמייצר רעש במשמרת, אספו עשר התראות אחרונות וסווגו את ה-Root Cause לפני שתציעו החרגה. לאחר מכן המשיכו למאמר על בניית Playbook ל-SOC כדי להפוך את תהליך הסגירה והמשוב לעקבי.

שאלות ותשובות

האם אפשר להגיע לאפס False Positives?

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

מה עדיף — Exception או שינוי חוק?

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

מה ההבדל בין False Positive ל-Benign Positive?

False Positive הוא זיהוי שגוי; Benign Positive הוא זיהוי נכון של פעילות חשודה אך מאושרת וצפויה.

מי צריך לאשר החרגה?

לפי ממשל הארגון: לרוב Detection Engineer או בעל החוק, ולעיתים בעל מערכת או מנהל SOC. החרגות בעלות סיכון גבוה דורשות ביקורת רחבה יותר.

מתי למחוק Exception?

כאשר הסיבה הסתיימה, הכלי הוסר, החוק שופר או שפג התוקף. יש לבדוק Exceptions באופן תקופתי ולא להשאירם לצמיתות כברירת מחדל.

מקורות

רוצים לבדוק אם המסלול מתאים לכם?

השאירו פרטים ונציג של HPI יחזור אליכם לשיחת התאמה קצרה וללא התחייבות.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI

רוצים לשמוע פרטים על התוכנית? השאירו פרטים ונחזור אליכם.

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI יצירת קשר

על הכותב

תאיר מלכא

מייסד ומנכ״ל HPI ומרצה לסייבר

תאיר מלכא הוא מייסד ומנכ״ל HPI – המכללה למקצועות ההייטק, ומרצה לסייבר במסלולי ההכשרה של המכללה. במסגרת תפקידיו הוא אחראי על בניית תוכניות הלימוד המקצועיות של HPI בתחומי סייבר, IT ורשתות, ומוביל את הליווי המקצועי של הסטודנטים לאורך המסלול.

לפרופיל הכותב ↗

הקודם באשכול

Triage ב-SOC: איך מתעדפים התראות בלי לפספס אירוע אמיתי

הבא באשכול

Playbook ל-SOC: איך בונים תהליך תגובה עקבי להתראה