Rules of Engagement ו-Scope בבדיקת חדירות

אישור וסמכות

הנושא 'אישור וסמכות' הוא חלק מרכזי בעבודה על Rules of Engagement בבדיקת חדירות. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את in-scope assets, out-of-scope, time window, allowed techniques, stop conditions, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

In-scope ו-Out-of-scope

התהליך של Rules of Engagement בבדיקת חדירות נבנה משלבים עם נקודות עצירה. מגדירים מטרה, Scope, מקורות, פעולות מותרות, ראיות נדרשות, בעלי תפקידים וקריטריון סיום. בסביבות התקפיות מוסיפים Stop conditions וערוץ חירום.

בכל שלב צריך להיות Output ברור: מפת נכסים, Timeline, Finding, Rule, Playbook או דוח. המעבר לשלב הבא מתבצע רק כאשר ה-Output מספיק ואמין; כך נמנעת עבודה אקראית או הרחבת Scope ללא אישור.

חלונות זמן ומקורות

בשלב זה מגדירים אילו ראיות דרושות כדי לענות על שאלת החקירה. עבור Rules of Engagement בבדיקת חדירות, נקודות הבסיס הן Scope ו-ROE, שעת בדיקה ומקור, Request/Response או פלט כלי, השפעה מוכחת במעבדה. לכל מקור מתעדים בעלים, טווח שמירה, אזור זמן, עיכוב קליטה ושדות שעלולים להיות חסרים.

איכות איסוף אינה נמדדת בכך שהלוג 'מגיע'. יש לבדוק Completeness, Latency, Parsing, Duplicate events וסנכרון זמן. בדיקת Canary או אירוע מעבדה ידוע מאפשרת לוודא שהפעולה הופיעה במקור, עברה את ה-Pipeline וניתנת לחיפוש בשדות הנכונים.

מגבלות טכניות ו-Banned actions

הנושא 'מגבלות טכניות ו-Banned actions' הוא חלק מרכזי בעבודה על Rules of Engagement בבדיקת חדירות. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את in-scope assets, out-of-scope, time window, allowed techniques, stop conditions, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

תקשורת, עצירה ודיווח

הנושא 'תקשורת, עצירה ודיווח' הוא חלק מרכזי בעבודה על Rules of Engagement בבדיקת חדירות. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את in-scope assets, out-of-scope, time window, allowed techniques, stop conditions, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

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

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: in-scope assets, out-of-scope, time window, allowed techniques, stop conditions, contacts. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

• in-scope assets: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• out-of-scope: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• time window: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• allowed techniques: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• stop conditions: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• contacts: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

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

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

1. הגדירו Scope ושאלת עבודה אחת בנושא Rules of Engagement בבדיקת חדירות.
2. רשמו את מקורות הנתונים והראיות הדרושים: in-scope assets, out-of-scope, time window, allowed techniques.
3. צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
4. בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
5. בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
6. בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
7. סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

Checklist מעשי

• ✓בדקו ותעדו: Scope ו-ROE.
• ✓בדקו ותעדו: שעת בדיקה ומקור.
• ✓בדקו ותעדו: Request/Response או פלט כלי.
• ✓בדקו ותעדו: השפעה מוכחת במעבדה.
• ✓בדקו ותעדו: Risk rating.
• ✓בדקו ותעדו: Remediation ו-Retest.
• ✓ציינו Time zone, גרסת כלי ושעת איסוף.
• ✓שמרו את הנתון הגולמי לפני סינון או שינוי.
• ✓כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
• ✓הגדירו בעלים ופעולת המשך עם מועד.

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

• להתחיל בדיקה בלי Scope חתום.
• להשתמש ב-Exploit אגרסיבי כברירת מחדל.
• לא לשמור Evidence.
• לדווח רק על CVSS בלי הקשר.
• לא להציע תיקון ישים.
• לא לבצע Retest.

סיכום ו-CTA

Rules of Engagement ו-Scope בבדיקת חדירות הוא נושא שמחבר ידע טכני למשמעת עבודה. התחילו משאלה, אספו רק ראיות רלוונטיות, שמרו הקשר וזמן, ובחרו פעולה שאפשר להצדיק ולבדוק מחדש.

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

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

מקורות

• NIST SP 800-115 — Technical Guide to Security Testing
• OWASP Web Security Testing Guide
• MITRE ATT&CK — Reconnaissance
• CIS Controls
• OWASP ASVS