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

Severity מול Priority: איך מדרגים אירועי אבטחה

מאת תאיר מלכא 6 דק׳ קריאהפורסם: 5 באוגוסט 2026
המחשה חזותית מקצועית בנושא Severity מול Priority באבטחת מידע בתחום SOC ותפעול
תשובה מהירה

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

במערכות SOC מופיעים לעיתים כמה ציונים במקביל: Alert Severity, Incident Severity, Risk Score, Magnitude או Priority. כאשר הצוות משתמש בהם כאילו הם אותו דבר, התוצאה היא תור עבודה לא עקבי: אירוע “High” ישן ומבודד דוחק הצידה פעילות “Medium” שמתרחשת עכשיו על חשבון מנהל.

Microsoft מתארת Severity כמדד להשפעה האפשרית על הנכסים, בעוד תור האירועים המאוחד מוסיף מנגנון Priority שמביא בחשבון גם קריטיות נכס, נדירות, טכניקות MITRE ואיומים בעלי פרופיל גבוה. ב-QRadar, Magnitude של Offense מחושב משילוב Severity, Relevance ו-Credibility יחד עם גורמים נוספים. הדוגמאות ממחישות שאין ציון יחיד שמתאים לכל החלטה.

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

מהי Severity

Severity מתארת את חומרת התוצאה האפשרית או שנצפתה: פגיעה בסודיות, בשלמות או בזמינות; מספר נכסים ומשתמשים; קריטיות המערכת; רגישות הנתונים; ורמת השליטה של התוקף. היא עונה על השאלה: “אם התרחיש אמיתי, כמה חמור הוא?”

ברוב הכלים הערכים הם Informational, Low, Medium ו-High, ולעיתים Critical. חשוב להבין מי קבע את הערך: יצרן Detection, Rule מקומי, מנוע אנליטי או אנליסט. Alert Severity יכולה לעבור בירושה ל-Incident, אך לאחר חקירה מותר ולעיתים נדרש לעדכן אותה.

Severity אינה הוכחה לאמיתות. חוק High בעל False Positive גבוה אינו הופך כל התאמה לאירוע חמור. לכן יש להפריד בין חומרה לבין Confidence.

מהי Priority

Priority קובעת את סדר הטיפול ואת רמת הדחיפות. היא עונה: “במה נטפל קודם?” מעבר לחומרה, היא מתחשבת בזמן, במצב האירוע, ביכולת הבלימה, באנשים הזמינים, ב-SLA ובהקשר העסקי.

אירוע Ransomware פעיל על תחנה אחת עשוי לקבל Priority קריטית בשל מהירות ההתפשטות, גם לפני שה-Scope ידוע. לעומתו, דלף היסטורי חמור שכבר נבלם עשוי להישאר Severity גבוהה אך Priority נמוכה יותר לחקירה מיידית, כל עוד אין פגיעה פעילה.

Priority צריכה להיות דינמית. עם גילוי נכס נוסף, הצלחת התחברות, שינוי Privilege או כשל ב-Containment — מעלים אותה. לאחר בידוד, Revoke ואימות שאין התפשטות — ניתן להפחית דחיפות בלי לשנות בהכרח את חומרת האירוע.

למה שני המדדים שונים

אם משתמשים רק ב-Severity, תור העבודה נשלט על ידי הציון הראשוני של הכלי. אם משתמשים רק ב-Priority ידנית, קשה להשוות אירועים ולבצע Review. השילוב הנכון הוא Severity יציבה יחסית שמתארת Impact, ו-Priority תפעולית שמתעדכנת לפי מצב האירוע.

אפשר להוסיף Confidence או Likelihood כציר שלישי. לדוגמה: Severity גבוהה, Confidence נמוך, Priority בינונית עד אימות; או Severity בינונית, Confidence גבוה ואירוע פעיל — Priority גבוהה.

ב-QRadar, Magnitude הוא דוגמה לציון משולב: Severity, Relevance ו-Credibility יחד עם Asset Weight, מספר Events, גיל ה-Offense ופגיעויות. הוא מועיל לתעדוף, אך עדיין דורש הבנת ההקשר.

גורמים שמשפיעים על Severity

  • Impact על סודיות, שלמות וזמינות.
  • קריטיות הנכס והשירות העסקי.
  • רגישות המידע והיקפו.
  • רמת הגישה: User, Local Admin, Domain Admin או Cloud Admin.
  • מספר הנכסים, המשתמשים והסביבות המעורבים.
  • שלב התקיפה: Initial Access לעומת Exfiltration או Impact.
  • יכולת התאוששות והאם קיימים גיבויים תקינים.

גורמים שמשפיעים על Priority

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

מטריצת דירוג מעשית

אפשר להתחיל ממטריצה של Severity ו-Confidence, ואז להתאים Priority לפי מצב פעילות וקריטיות. אין נוסחה אוניברסלית; המודל צריך להיות שקוף, מתועד ונבדק על אירועים אמיתיים.

מומלץ להוסיף לכל החלטה שורת Reason. “Priority High — Active session on privileged identity; containment not completed” ברורה יותר מציון לבדו.

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

דוגמאות מה-SOC

תרחישSeverityPriorityהנמקה
Malware ישן שנמצא בקובץ Archive מבודדגבוההנמוכה-בינוניתפוטנציאל חמור, אך אין ביצוע פעיל
Password Spray פעיל ללא הצלחהבינוניתגבוההחלון בלימה קצר והיקף משתמשים
Login ל-Global Admin ממדינה חדשהגבוההקריטיתזהות רגישה וסשן אפשרי פעיל
שרת Production לא שולח לוגיםבינוניתגבוההאובדן נראות בנכס קריטי
Adware בתחנת מעבדה מנותקתנמוכהנמוכההשפעה מוגבלת ו-Containment קיים

איך מעדכנים דירוג לאורך החקירה

קבעו נקודות Review: לאחר Triage, לאחר Scope ראשוני, אחרי פעולה ראשונה ולפני סגירה. בכל נקודה שאלו מה השתנה ב-Impact, Confidence ובמצב הפעילות. עדכון ציון צריך לכלול Timestamp, Owner ונימוק.

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

במדדי צוות, נתחו גם Reclassification: כמה אירועים עלו או ירדו בדרגה, ומה גרם לכך. שינוי עקבי יכול להצביע על Rule שמסווג לא נכון או על Asset Criticality שאינה מעודכנת.

Checklist מעשי

  • האם ברור מי קבע את ה-Severity הראשונית?
  • האם הערכתי Impact ולא רק שם Detection?
  • האם Confidence מתועד בנפרד?
  • האם האירוע פעיל או נבלם?
  • האם נכס/זהות קריטיים מעורבים?
  • האם ה-Priority כוללת נימוק תפעולי?
  • האם נקבעה נקודת Review הבאה?
  • האם שינוי ציון נשמר ב-Audit Trail?

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

  • לסמן כל Alert High כאירוע Critical.
  • להשתמש ב-Severity וב-Priority כמילים נרדפות.
  • לא לעדכן דירוג לאחר בידוד או הרחבת Scope.
  • להתעלם מקריטיות נכס ומרגישות מידע.
  • לבנות נוסחה מורכבת שאיש אינו מבין.
  • למדוד SLA באופן שמעודד הורדת Severity מלאכותית.

סיכום ו-CTA

בנו מטריצה של חמישה תרחישים מהמעבדה ותנו לכל אחד Severity, Confidence ו-Priority עם משפט נימוק. השוו את התוצאה למאמר על Triage ולקריטריוני ההסלמה. בקורס Cybersecurity & AI של HPI מתרגלים קבלת החלטות על בסיס הקשר ולא רק קריאת ציון מהמערכת.

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

האם Severity של היצרן מחייבת את הארגון?

לא. היא נקודת פתיחה. יש להתאים אותה לסביבה, לנכס, ל-Scope ולמדיניות המקומית.

האם Priority יכולה להיות גבוהה יותר מ-Severity?

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

מתי משנים Severity?

כאשר ראיות משנות את הערכת ההשפעה או ה-Scope. שינוי צריך להיות מתועד עם נימוק.

מהו Magnitude ב-QRadar?

ציון שמסייע לתעדף Offenses ומחושב, בין היתר, לפי Severity, Relevance, Credibility, נכסים ואירועים. הוא אינו זהה ל-Severity בלבד.

האם צריך Critical מעל High?

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

מקורות

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

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

פרטייך נשמרים באופן מאובטח.

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

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

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

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

מאמרים קשורים