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

Alert, Event, Incident ו-Offense: ההבדלים שכל אנליסט צריך להכיר

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

Event הוא רשומה או פעילות שנצפתה; Alert הוא הודעה שנוצרה כאשר מנגנון זיהוי מצא התאמה או חריגה; Incident הוא אוסף ממצאים שנקבע כי מצריך חקירה ותגובה; Offense הוא אובייקט החקירה של IBM QRadar, שנוצר מקורלציה של Events ו-Flows לפי Rules. המונחים אינם זהים בין מוצרים, ולכן אנליסט צריך להבין גם את המשמעות הכללית וגם את מודל הנתונים של הכלי שבו הוא עובד.

אנליסט מתחיל פוגש מילים דומות בכל מסך: Event, Alert, Incident, Case, Finding ו-Offense. קל להניח שכל אחת מתארת “אירוע סייבר”, אך בפועל הן מייצגות שכבות שונות של נתונים והחלטות. הבלבול משפיע על חיפוש, תיעוד, מדדים והסלמה.

NIST מגדיר Cybersecurity Incident כאירוע סייבר שנקבע שיש לו השפעה על הארגון ולכן נדרשות תגובה והתאוששות. Microsoft מתארת Incident כאוסף Alerts קשורים שמספרים את סיפור התקיפה. IBM QRadar משתמשת במונח Offense לאובייקט פעולה שנוצר כאשר Events ו-Flows עומדים בתנאי Rules. לכן אי אפשר לתרגם כל מונח אוטומטית בלי להבין את ההקשר.

המדריך בונה את השרשרת מהלוג הגולמי ועד Case חקירה ומסביר איפה נכנסת החלטה אנושית.

Event: התצפית הבסיסית

Event הוא תיעוד של פעולה, מצב או שינוי. דוגמאות: התחברות מוצלחת, כשל אימות, יצירת Process, שאילתת DNS, שינוי Policy או חיבור רשת. רוב ה-Events לגיטימיים; ערכם מגיע מהשדות ומההקשר.

Event יכול להגיע מ-Raw Log, Telemetry של EDR, Audit Log בענן או Flow ברשת. SIEM מבצע Parsing ונרמול כדי להציג שדות אחידים, אך הרשומה עדיין אינה טענה שהתרחשה תקיפה.

איכות Event תלויה במקור: Timestamp, Host, User, Action, Result ומזהה ייחודי. Event חסר או שגוי יכול לגרום ל-Alert מטעה, ולכן חקירה מקצועית חוזרת לעיתים ל-Raw Data.

Alert: אות שנוצר מלוגיקה

Alert נוצר כאשר כלל, מודל, חתימה או Analytics מזהים התאמה. הוא עשוי להתבסס על Event יחיד, רצף, Threshold, Anomaly או IOC. Alert אומר “כדאי לבדוק”, לא “האירוע זדוני”.

Alert כולל בדרך כלל Title, Severity, זמן, Entities, Evidence ושם Detection. הוא יכול להיות True Positive, Benign Positive או False Positive. תפקיד ה-Triage הוא להבין אם יש מספיק הקשר לפתוח חקירה, לסגור או להעשיר.

במערכות שונות Alert יכול להיקרא Detection, Finding או Signal. חשוב לבדוק בתיעוד המוצר האם מדובר בתוצאה גולמית, באגרגציה או כבר באובייקט חקירה.

Incident: סיפור חקירה ותגובה

Incident מרכז Alerts, Entities, Evidence, Timeline ופעולות סביב תרחיש אחד. ב-Microsoft Defender XDR, Alerts קשורים מקובצים כדי להציג את סיפור התקיפה על פני Endpoint, Identity, Email ו-Cloud. Incident יכול להתעדכן ככל שמגיע מידע חדש.

ברמה ארגונית, Incident אינו רק אובייקט טכני. הוא כולל Owner, Status, Severity, Classification, Tasks, Comments ותגובה. ייתכן Alert אמיתי שלא יהפוך ל-Incident אם הוא בעל השפעה זניחה ומטופל אוטומטית; וייתכן Incident שנפתח ידנית בעקבות דיווח משתמש גם ללא Alert אוטומטי.

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

Offense ב-QRadar

QRadar אוסף Events ו-Flows ומפעיל Custom Rule Engine. כאשר תנאים מתקיימים, Rule יכולה לתרום ליצירת Offense. Offense מרכז את ה-Events וה-Flows הקשורים ומציג Context לחקירה.

Offense אינו מילה כללית לכל Incident. זהו אובייקט ספציפי למודל QRadar. הוא כולל Magnitude שמחושב לפי Severity, Relevance, Credibility וגורמים נוספים. האנליסט פותח את ה-Offense, בודק Rules, Events, Source/Destination, Assets, Notes ו-Timeline.

לעיתים Offense מייצג חשד למדיניות או תקיפה, אך עדיין נדרש לסווגו. הוא יכול להיסגר כ-False Positive, Non-Issue, Policy Violation או לפי Taxonomy מקומית.

Finding, Case ו-Detection

Finding הוא ממצא שדורש תשומת לב, נפוץ בכלי Cloud ו-Vulnerability. Detection יכולה להיות לוגיקת הזיהוי או התוצאה שלה, לפי המוצר. Case הוא מעטפת עבודה רחבה שמרכזת כמה Incidents או חקירה חוצת מערכות.

במקום להתווכח על “המילה הנכונה”, בנו מילון ארגוני: שם המונח, המקור, מה הוא מייצג, מי Owner, אילו Status קיימים ומה יוצר או סוגר אותו. המילון חשוב במיוחד כאשר מחברים כמה מוצרים ל-SOAR.

שרשרת הדוגמה מלוג עד Incident

1. Domain Controller רושם Event של חמישים כשלונות כניסה מכתובת אחת. 2. SIEM Rule סופר את האירועים בחלון של חמש דקות ויוצר Alert של Password Spray. 3. Alert נוסף מציג Login מוצלח לאחד המשתמשים. 4. מנוע קורלציה מאחד את שני ה-Alerts ל-Incident. 5. אנליסט בודק Scope, מבטל Sessions ומסווג את ה-Incident כ-True Positive.

ב-QRadar, אותם Events ו-Flows עשויים להפעיל Rules וליצור Offense שמציג את מקור התקיפה, המשתמשים, Magnitude והאירועים התורמים. המידע דומה, אך השמות והיחסים בין האובייקטים שונים.

טבלת השוואה

מונחמה הוא מייצגמי יוצר אותוהאם דורש תגובה?
Eventפעולה או רשומת Telemetryמערכת מקור/Collectorבדרך כלל לא לבד
Alertאות שנוצר מזיהויRule, Model או מוצר אבטחהדורש Triage
Incidentחקירה מרוכזת של השפעה/תקיפהCorrelation, Analyst או Workflowכן, לפי Classification
Offenseאובייקט חקירה ב-QRadarCustom Rule Engine וקורלציהדורש חקירה ותעדוף
Findingממצא אבטחה או סיכוןScanner, Cloud service או Analystתלוי בסוג ובהשפעה
Caseמעטפת ניהול רחבהAnalyst/SOAR/Case systemכן, לפי Scope

תרגיל מיון

פריטסיווג סבירהסבר
Event ID 4625 יחידEventרשומת כשל כניסה
Rule: 20 כשלונות ב-2 דקותAlertלוגיקת זיהוי מצאה Threshold
שני Alerts על אותו משתמש ומכשירIncidentסיפור משותף לחקירה
QRadar מציג Magnitude 8 עם 300 EventsOffenseאובייקט חקירה של QRadar
CSPM מזהה Storage ציבוריFindingממצא תצורה/סיכון
חקירה חוצת שלושה TenantsCaseמעטפת רחבה לכמה Incidents

Checklist מעשי

  • בדקתי את הגדרת המונח בתיעוד המוצר.
  • אני יודע מה המקור וה-Trigger של כל אובייקט.
  • לא התייחסתי ל-Alert כהוכחה לתקיפה.
  • קישרתי Events ל-Alerts ול-Incident באמצעות מזהים.
  • תיעדתי Classification ו-Owner.
  • בניתי מילון מונחים לצוות ול-SOAR.

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

  • לקרוא לכל שורת לוג “Incident”.
  • להשתמש ב-Offense מחוץ להקשר QRadar כאילו הוא תקן כללי.
  • לספור Events ו-Incidents באותו מדד.
  • לסגור Alert בלי לבדוק אם הוא חלק מ-Incident רחב.
  • להניח שהמונחים זהים בין Sentinel, Defender, QRadar ו-Elastic.
  • לא לשמור קשר בין האובייקטים במערכת Ticketing.

סיכום ו-CTA

פתחו SIEM או תרחיש מעבדה ובחרו עשרה פריטים. סמנו לכל אחד אם הוא Event, Alert, Incident, Offense או Finding והסבירו מי יצר אותו. לאחר מכן עברו למאמר “מה זה SIEM ואיך הוא עובד” כדי להבין את צינור הנתונים המלא. בקורס HPI מתרגלים את המונחים בתוך כלי חקירה ולא רק כהגדרות.

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

האם כל Alert הופך ל-Incident?

לא. Alert יכול להיסגר ב-Triage, להיות מאוחד עם Incident קיים או להישאר כאות עצמאי לפי המוצר והמדיניות.

האם Incident חייב להכיל כמה Alerts?

לא. הוא יכול להתבסס על Alert אחד בעל משמעות, או להיפתח ידנית בעקבות דיווח או Evidence אחר.

מה ההבדל בין Incident ל-Case?

Incident עוסק בדרך כלל בתרחיש אבטחה מוגדר; Case יכול להיות מעטפת רחבה לכמה Incidents, חקירה משפטית או קמפיין.

האם Offense הוא Incident?

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

מה סופרים בדוח SOC?

יש להפריד בין נפח Events, מספר Alerts, מספר Incidents ו-Classifications. ערבוב ביניהם יוצר מדדים חסרי משמעות.

מקורות

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

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

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

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

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

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

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

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