QRadar Offense: איך קוראים וחוקרים Offense

מה יוצר Offense

Rule ב-QRadar היא אוסף Tests שמופעלים על Event, Flow, סדרת אירועים, Offense או שילוב אחר בהתאם לסוג החוק. כאשר התנאים מתקיימים, Response יכולה ליצור Offense, להוסיף נתונים ל-Reference set, לשלוח הודעה או לבצע פעולה אחרת. שם ה-Rule הוא נקודת התחלה בלבד; על האנליסט להבין את ה-Test stack ואת Scope הנתונים.

לפני פתיחת Raw events, שאלו: האם זה Event rule או Flow rule? האם מדובר ב-Threshold בחלון זמן? האם התנאי Stateful? האם Rule מסתמכת על Building Block שמגדיר קבוצה, למשל “שרתי דואר” או “סורקי פגיעויות”? האם ה-Offense משויך ל-Source IP, Destination IP, Username או מאפיין אחר?

Magnitude, Relevance, Credibility ו-Severity

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

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

Events ו-Flows: שתי עדשות

Event מתאר בדרך כלל רשומת לוג: Authentication, Firewall deny, Process, Audit או אירוע אפליקטיבי. Flow מתאר שיחה או תקשורת רשתית: מקור, יעד, Ports, Protocol, Bytes, Packets וזמנים. Offense יכול לכלול אחד מהם או את שניהם. חיבור Event ו-Flow מאפשר לבדוק לא רק “מה המוצר דיווח”, אלא גם “האם התעבורה התרחשה ומה היה היקפה”.

בחקירה פתחו את רשימת Events, מיינו לפי זמן וקטגוריה, ובדקו QID, Log Source, Username, Payload ושדות מותאמים. לאחר מכן עברו ל-Flows: האם ה-Source פנה ליעד? האם הייתה תקשורת דו-כיוונית? מה היה נפח הנתונים? האם Port תואם לשירות הצפוי? היעדר Flow אינו מוכיח שלא הייתה תקשורת; ייתכן שאין כיסוי NetFlow באותו Segment.

Source, Destination ו-Assets

QRadar מקשרת Offense לפי “Offense source” שנקבע על ידי החוק והאירועים. לעיתים ה-Source הוא כתובת חיצונית, לעיתים משתמש, Host פנימי או יעד. אל תניחו שהשדה Source הוא תמיד תוקף. בדוגמת Malware callback, Source פנימי עשוי להיות תחנה נפגעת; בדוגמת Scan, Source עשוי להיות Scanner ארגוני מורשה.

Asset context משנה תעדוף: שרת Domain Controller, תחנת אדמין ושרת בדיקות אינם זהים. בדקו Asset weight, Owner, Network hierarchy, פתחים, Vulnerabilities וקשרים עסקיים. אם QRadar לא מזהה את הנכס או מזהה אותו בשם ישן, ציינו זאת כחסר בראיות.

Workflow חקירה של Offense

1. קראו את Description, Rule(s), Offense type, Source, Destination, Magnitude, Start time ו-Last event.
2. פתחו את Rule או את פרטי החוק והבינו את Tests, Threshold, חלון הזמן ו-Building Blocks.
3. עברו על Events התורמים. קבצו לפי QID, Log Source, Username, Source ו-Destination כדי לזהות חזרתיות וכפילויות.
4. בדקו Flows קשורים, אם קיימים, וחפשו תקשורת לפני ואחרי ה-Event המרכזי.
5. אמתו Network hierarchy ו-Asset profile. שאלו האם הכתובות פנימיות, VPN, NAT, Proxy או Shared infrastructure.
6. בנו Timeline וחיפוש משלים ב-Log Activity וב-Network Activity לטווח רחב יותר.
7. בדקו Offenses נוספים על אותם נכסים, משתמשים, Domains או Rules. קשר בין מקרים יכול להרחיב Scope.
8. סווגו, תעדו Notes, הקצו Owner והחליטו האם להסלים, לסגור או להשאיר במעקב.

תרחיש: כמה מקורות מול יעד קריטי

במעבדה נוצר Offense בשם “Multiple authentication failures followed by success” על שרת קבצים קריטי. Magnitude הוא 8, קיימים 180 Events משלושה Log Sources, וה-Offense source הוא IP פנימי. טבלת העבודה יכולה להיראות כך:

אם Source הוא שרת ניהול והכשלונות תואמים Job שנכשל אחרי החלפת סיסמה, ייתכן Benign Positive. אבל Success ואחריו SMB ל-Share רגיש עדיין דורשים אימות של החשבון והפעולה. אם אין Change מאושר, יש להסלים ל-IR או לצוות זהויות בהתאם ל-Playbook.

סגירה, Notes ו-Tuning

Notes צריכות לכלול היפותזה, ראיות, חיפושים שבוצעו, חסרים, Classification ופעולות. Closing Reason צריך להיות עקבי כדי לאפשר Metrics ו-Tuning. “False Positive” ללא הסבר אינו מספיק; ציינו אם השורש הוא Scanner מורשה, Parser שגוי, Threshold, Duplicate, Asset context או פעילות משתמש לגיטימית.

Tuning יכול לכלול שינוי Rule, Building Block, Reference set, Network hierarchy, Log source credibility או Asset weight. כל שינוי צריך Owner, תיעוד, בדיקת Regression ותאריך Review. אל תחריגו Source IP שלם אם ניתן להחריג רק Event name, Destination, חלון תחזוקה או Service account.

Checklist

• ✓הבנתי מה יצר את ה-Offense ואילו Rules תרמו.
• ✓פירקתי Magnitude לרכיבי הקשר ולא השתמשתי בו כהוכחה.
• ✓בדקתי Events וגם Flows כאשר קיימים.
• ✓אימתתי Source, Destination, NAT, Proxy ו-Network hierarchy.
• ✓בדקתי Asset criticality ו-Vulnerabilities.
• ✓בניתי Timeline וחיפשתי פעילות לפני ואחרי.
• ✓כתבתי Notes ו-Closing Reason מפורטים.
• ✓העברתי Tuning ממוקד עם Owner ו-Review date.

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

• לסגור לפי Magnitude נמוך בלי לפתוח את האירועים.
• להניח ש-Offense source הוא תוקף.
• לספור Events בלי לבדוק כפילויות או Aggregation.
• להתעלם מ-Flows או מהיעדר כיסוי תעבורה.
• לסמוך על Asset profile לא מעודכן.
• לשנות Rule בייצור ללא Baseline ו-Regression test.

סיכום ו-CTA

בחרו Offense מעבדה וכתבו דף חקירה בן עמוד: מה יצר אותו, מה אומר Magnitude, אילו Events ו-Flows תורמים, מי ה-Source וה-Destination, מהו Asset context ומהי החלטת הסגירה. לאחר מכן השוו בין הדף לבין Ticket של אנליסט אחר. התרגיל מלמד לעבוד עם QRadar כזירת חקירה ולא רק כתור התראות.

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

מקורות

• IBM Documentation — Offense prioritization
• IBM Documentation — QRadar rules and offenses
• IBM Documentation — Custom rules
• IBM Documentation — Reference sets overview
• IBM Documentation — Investigating offenses