סייבר ואבטחת מידע · siem-detection

SIEM Tuning: איך מפחיתים Alert Fatigue בלי לפגוע בכיסוי

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

המחשה חזותית מקצועית בנושא SIEM Tuning בתחום SIEM וזיהוי

תשובה מהירה

SIEM Tuning הוא תהליך שבו מגדירים Use Case, מאמתים את מקור הנתונים, בודקים Parsing ונרמול, מריצים בדיקות איכות ומוודאים שהפלט מאפשר חקירה ולא רק הצגת Alert.

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

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

התרחיש המעשי במאמר הוא: Tuning לחוק שמתריע על כלי ניהול לגיטימי.. כל הדוגמאות הן נתוני מעבדה או תיאור תהליכי. כאשר מדובר ב-Penetration Testing, Web או Cloud, יש לעבוד רק עם אישור מפורש, Scope מוגדר ויכולת לעצור את הבדיקה.

מדידת רעש לפני שינוי

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

אפשרויות Tuning כוללות סף, חלון זמן, Allowlist ממוקדת, Context של נכס, Suppression וחריג מבוסס תהליך מאושר. כל חריג צריך בעלים, תוקף ותנאי ביטול. לאחר השינוי מריצים Test corpus ומשווים לפני/אחרי.

סיווג סיבות לרעש

אפשרויות Tuning

בדיקת השפעה על True Positives

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

יש להפריד בין Severity — חומרת התרחיש — לבין Priority — סדר הטיפול. תיעוד טוב מסביר את הגורמים לדירוג, ולא מציג מספר בודד כאמת מוחלטת.

Change control ו-Rollback

הנושא 'Change control ו-Rollback' הוא חלק מרכזי בעבודה על SIEM Tuning. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

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

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: מקור הלוג וה-Connector, זמן האירוע וזמן הקליטה, שדות גולמיים ומנורמלים, חוק הזיהוי וגרסתו, ישויות, Enrichment והקשר עסקי, פערי Coverage או Latency. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

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

כאשר אחד המוקדים אינו זמין, יש לתעד את הפער ולבחור חלופה. לדוגמה, אם Process identifier אינו יציב, אפשר להיעזר בזמן, Host, User ו-Parent; אם Payload מוצפן, משתמשים ב-Metadata, נפח, תדירות ו-TLS/DNS context.

תהליך עבודה מומלץ

הגדירו Scope ושאלת עבודה אחת בנושא SIEM Tuning.
רשמו את מקורות הנתונים והראיות הדרושים: מקור הלוג וה-Connector, זמן האירוע וזמן הקליטה, שדות גולמיים ומנורמלים, חוק הזיהוי וגרסתו.
צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

שלב	מה מבצעים	תוצר
הכנה	הגדירו Scope, זמן ויעד. רשמו אילו שדות או ראיות מתוך מקור הלוג וה-Connector, זמן האירוע וזמן הקליטה, שדות גולמיים ומנורמלים צפויים להופיע.	תוכנית בדיקה קצרה
יצירת נתון	בצעו פעולה בטוחה ומדומה הקשורה ל-SIEM Tuning, ללא מידע אמיתי או השפעה על מערכת ייצור.	אירוע/Request/Flow מבוקר
איסוף	אספו את הראיה הגולמית ואת ההקשר ממקור נוסף. ודאו Time zone, מזהים ושלמות.	שתי ראיות מקושרות
ניתוח	כתבו מה כל ראיה מוכיחה, מה אינה מוכיחה ומהו ההסבר הלגיטימי האפשרי.	מסקנת ביניים
סיום	בחרו סגירה, הסלמה, Finding או Tuning; הוסיפו המלצה ו-Retest.	תוצר מתועד

Checklist מעשי

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

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

לחבר נתונים לפני שהוגדר Use Case.
להניח שכל שדה מנורמל נכון.
לכוון חוק לפי דוגמה אחת בלבד.
להשתיק רעש בלי בדיקת Regression.
למדוד רק כמות Alerts.
להתעלם מתקלה במקור הלוגים.

סיכום ו-CTA

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

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

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

האם SIEM Tuning לבדו מוכיח תקיפה או חולשה?

לא. הוא מספק אות או ממצא שצריך הקשר, אימות ומקור נוסף. מסקנה מקצועית נשענת על רצף ראיות ועל התאמה להתנהגות הצפויה.

מה עושים כאשר חלק מהנתונים חסרים?

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

כמה זמן צריך לשמור את הראיות?

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

איך מתרגלים בלי לסכן מערכת אמיתית?

משתמשים במכונות וירטואליות, נתונים מדומים, CTF או מעבדה ייעודית. בבדיקות מורשות מגדירים Scope, Stop conditions וגיבוי לפני תחילת העבודה.

מקורות

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

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

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

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

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

על הכותב

תאיר מלכא

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

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

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

הקודם באשכול

איך מחברים מקור לוגים ל-SIEM ומוודאים שהמידע אמין

הבא באשכול

Windows Event Logs לאנליסט SOC: מאיפה מתחילים