QRadar Rules and Building Blocks: מדריך מעשי

כיצד CRE מעריך Events ו-Flows

כאשר Event או Flow מגיע ל-QRadar, הוא מנורמל ומועבר דרך CRE. המנוע בוחן Rules רלוונטיות לפי סוג הנתון. Test יכול לבדוק Property פשוט, קטגוריה, Log Source, Network location, ערך ברשימה, Regex ב-Payload או רצף לאורך זמן. אם כל התנאים מתקיימים, Rule Response מופעלת.

סדר Tests חשוב לביצועים. IBM ממליצה להתחיל בתנאים שמצמצמים את כמות הנתונים: Log Source Type, Network, Event category או Direction. לאחר מכן מוסיפים IP, Port, Username או מאפיינים אחרים. Payload ו-Regular Expression צריכים להגיע מאוחר, משום שהם יקרים יותר. Rule שמפעילה Regex על כל Events בארגון עלולה ליצור עומס גם אם התוצאה נכונה.

Rule לעומת Building Block

Building Block אינו “Rule חלש”. הוא ספריית לוגיקה. לדוגמה, BB:Approved Scanners יכול להכיל IPs או Network ranges של סורקי פגיעויות. Rule לזיהוי Scan חיצוני יכולה להוסיף תנאי NOT when source matches BB:Approved Scanners. אם הסורק משתנה, מעדכנים רכיב אחד.

עם זאת, שימוש יתר ב-Building Blocks יוצר שרשרת תלות שקשה להבין. תעדו Owner, Purpose ו-Consumers. שם כמו BB:Temp2 אינו שימושי. שם טוב מסביר Scope, לדוגמה BB:HostDefinition:DomainControllers או BB:UserDefinition:PrivilegedAccounts.

סוגי Rules

QRadar תומכת בסוגי Rules שונים. Event rules בוחנות נתוני Log Activity. Flow rules בוחנות Network Activity. Common rules יכולות לעבוד עם מאפיינים משותפים ל-Events ול-Flows. Offense rules בוחנות מאפייני Offense כדי להפעיל Responses נוספים. הבחירה צריכה להתאים לנתון ולאילוץ.

אם השאלה היא “האם משתמש נכשל בהתחברות פעמים רבות?”, Event rule מתאימה. אם השאלה היא “האם Host יצר תעבורה לנפח חריג?”, Flow rule עשויה להתאים. אם צריך להגיב רק כאשר Offense מסוים עבר Magnitude או קיבל מאפיין, Offense rule יכולה להיות רלוונטית.

Stateful Tests ו-Thresholds

Stateful Test זוכר פעילות לאורך חלון זמן. דוגמאות: יותר מ-N Events מאותו Source, פעילות מול יותר מ-M Destinations, או סדרת אירועים. יש להגדיר Key שעל פיו סופרים: Source IP, Username, Destination, שילוב שדות או ערך אחר. Key שגוי יערבב ישויות או יפצל Pattern.

Threshold צריך להתבסס על Baseline. עשרה כשלונות בחמש דקות עשויים להיות חריגים למשתמש רגיל אך צפויים בשרת RADIUS. חלון קצר מזהה Burst; חלון ארוך מזהה פעילות איטית אך מגדיל State ורעש. כתבו מראש מהו Threat behavior, לא רק “מספר שנראה הגיוני”.

Responses ו-Reference sets

Response יכולה ליצור Offense, לשלוח Email או Syslog, להוסיף ערך ל-Reference set, לבצע Dispatch של Action או פעולה אחרת בהתאם להרשאות ולגרסה. הפרידו בין Detection לבין Response: Rule יכולה להיות נכונה אך Response מסוכנת. בתחילת Tuning העדיפו יצירת Offense או Notification לפני Blocking אוטומטי.

Reference set הוא אוסף ערכים ייחודיים שניתן להשתמש בו בחיפושים, Filters, Tests ו-Responses. אפשר לשמור IOCs, משתמשים, IPs או Context עסקי. Rule יכולה לבדוק אם ערך נמצא ברשימה או להוסיף אותו. הגדירו Type, TTL או תהליך ניקוי, Owner ומקור. Reference set ישן של IOCs עלול לייצר False Positives או להסתיר פעילות אם משמש ל-Whitelist.

תרגיל: תכנון Rule רב-שלבית ל-Password Spray

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

לפני פריסה בדקו נתוני VPN, Proxy ו-NAT. כתובת Source משותפת יכולה לייצג משתמשים רבים לגיטימיים. ייתכן שצריך Key משולב של Source, Application ו-Tenant. בדקו גם אם Username מנורמל; שינוי אותיות או Domain prefix עלול לנפח את מספר המשתמשים הייחודיים.

Testing ו-Tuning

1. כתבו Detection specification: Threat behavior, Data source, fields, key, threshold, window, exceptions ו-response.
2. הריצו Historical search כדי להבין Baseline. CRE פועלת בזמן אמת, אך חיפוש היסטורי עוזר להעריך נפח ודוגמאות.
3. בדקו Positive cases מדומים ו-Negative cases. ודאו שה-Rule אינה תלויה בשדה שחסר בחלק מה-Log Sources.
4. הפעילו בסביבת Test או במצב תגובה שמרני. מדדו Offense volume ו-Event contribution.
5. בדקו ביצועים: Tests רחבים בתחילה, Regex/Payload בסוף, והימנעות מ-Global rule אם Local מספיקה.
6. תעדו כל Exception עם סיבה, Owner ותאריך תפוגה. העדיפו Building Block או Reference set מנוהל.
7. לאחר שינוי בצעו Regression test על מקרים אמיתיים ומדומים.

Checklist לפני Enable

• ✓Use Case והאיום מנוסחים בשפה ברורה.
• ✓סוג Rule מתאים ל-Event, Flow או Offense.
• ✓Tests מסודרים מהמצמצם והזול אל היקר.
• ✓Grouping key, Threshold ו-Time window נבדקו.
• ✓Building Blocks מתועדים ואינם יוצרים תלות מעגלית.
• ✓Reference sets כוללים Owner, מקור ותהליך תפוגה.
• ✓Response בטוחה ומתאימה לרמת Confidence.
• ✓קיים Plan ל-Tuning, Metrics ו-Rollback.

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

• להתחיל מ-Regex על Payload במקום לסנן Log Source וקטגוריה.
• להעתיק Rule מסביבה אחרת בלי Network hierarchy ו-Asset context.
• להשתמש ב-Building Block כ-Whitelist גורף.
• להגדיר Global rule כאשר Local מספיקה.
• לספור לפי Source IP בסביבה עם NAT בלי Context נוסף.
• להוסיף ערכים ל-Reference set ללא Expiration.
• להפעיל תגובה אוטומטית לפני Tuning.

סיכום ו-CTA

בנו במעבדה Rule specification ל-Password Spray, אך אל תפרסו מיד. הציגו את ה-Tests לפי סדר, סמנו אילו מהם Stateless ואילו Stateful, הגדירו Building Block לתשתית מאושרת וכתבו Response שמרנית. לאחר מכן תנו לאדם אחר להסביר את החוק רק מתוך התיעוד. אם הוא אינו מצליח, החוק עדיין אינו מוכן.

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

מקורות

• IBM Documentation — QRadar rules and offenses
• IBM Documentation — IBM QRadar building blocks
• IBM Documentation — Custom rules
• IBM Documentation — Creating a custom rule
• IBM Documentation — Reference sets overview