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

איך כותבים Ticket חקירה מקצועי ב-SOC

מאת תאיר מלכא 6 דק׳ קריאהפורסם: 5 באוגוסט 2026

המחשה חזותית מקצועית בנושא כתיבת Ticket ב-SOC בתחום SOC ותפעול

תשובה מהירה

Ticket חקירה מקצועי ב-SOC צריך לאפשר לאנליסט אחר להבין מה קרה, אילו נתונים נבדקו, מה נמצא, מה עדיין לא ידוע ומה הפעולה הבאה — בלי שיחת השלמה. מבנה טוב כולל תקציר, Scope, Timeline, ראיות, ניתוח, החלטה, פעולות תגובה והמלצות. יש להפריד בבירור בין עובדה, פרשנות והשערה, ולצטט רק את שדות הלוג הרלוונטיים.

ב-SOC, ה-Ticket הוא לא “סיכום אדמיניסטרטיבי” שממלאים בסוף. הוא תוצר מקצועי שמלווה את החקירה, מאפשר הסלמה, שומר רציפות בין משמרות ומספק בסיס לשיפור Detection ול-Post-Incident Review. חקירה מצוינת שאינה מתועדת היטב עלולה להפוך לבלתי ניתנת לשחזור.

מערכות כמו Microsoft Defender ו-Microsoft Sentinel מאפשרות להקצות Owner, לשנות Severity ו-Status, להוסיף Tags, Classification ו-Comments. הכלים חשובים, אך איכות התיעוד תלויה בשיטה: האם הקורא יכול להבחין בין נתון מקורי למסקנה? האם הוא יודע אילו Queries הורצו? האם ניתן להבין מדוע ההתראה נסגרה או הוסלמה?

המדריך מציג תבנית שמתאימה ל-SIEM, מערכת Ticketing או Case Management, כולל דוגמה ל-Ticket חלש ולגרסה מקצועית.

למה Ticket הוא תוצר חקירה

Ticket טוב משרת כמה קהלים בו-זמנית: האנליסט הנוכחי, המשמרת הבאה, Tier 2, צוות IR, מנהל SOC ולעיתים גם IT או בעל מערכת. לכל אחד מהם יש צורך אחר, ולכן התיעוד צריך להיות שכבות: תקציר מהיר בראש, פירוט טכני בגוף וראיות או קישורים בנספח.

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

במקרה של אירוע מאומת, NIST מדגיש את חשיבות התיעוד והתיאום כחלק מיכולת התגובה. התיעוד אינו רק “מה עשינו”, אלא גם מתי, מי אישר, מה הייתה התוצאה ואילו מגבלות השפיעו על ההחלטה.

מבנה מומלץ ל-Ticket

פתחו בכותרת תיאורית ולא בשם חוק בלבד. “Encoded PowerShell on DC01 after privileged login” מועיל יותר מ-“Rule 4827”. בשורת התקציר כתבו את מי, מה, מתי ומצב נוכחי. אחריה הציגו Scope, Timeline, Evidence, Analysis, Actions ו-Next Steps.

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

חלק	מה כותבים	שאלה שהחלק עונה עליה
Title	התנהגות, ישות ונכס מרכזי	מה המקרה?
Executive Summary	2–4 שורות עם מצב נוכחי	מה חשוב לדעת עכשיו?
Scope	משתמשים, Hosts, IP, זמן ומערכות	על מי ועל מה האירוע משפיע?
Timeline	אירועים מהותיים לפי UTC	מה קרה ובאיזה סדר?
Evidence	לוגים, Hashes, Links, Screenshots מאושרים	על מה מבוססת המסקנה?
Analysis	עובדות, פירוש, חלופות ורמת ביטחון	מה משמעות הממצאים?
Actions	חסימות, בידוד, איפוס, פנייה לבעל מערכת	מה כבר בוצע?
Decision	True Positive, Benign Positive, False Positive או Open	מה הסיווג?
Next Steps	משימה, Owner ויעד זמן	מה צריך לקרות עכשיו?

עובדה, פרשנות והשערה

עובדה היא נתון שנצפה במקור: “Event ID 4688 תיעד powershell.exe בשעה 10:14:22 UTC”. פרשנות היא משמעות מקצועית: “Parent של WINWORD.EXE ושורת פקודה מקודדת מעלים חשד לביצוע ממסמך”. השערה היא אפשרות שטרם אומתה: “ייתכן שהמשתמש פתח קובץ Phishing”.

כאשר שלוש השכבות נכתבות באותו משפט, הקורא עלול להתייחס להשערה כעובדה. לכן השתמשו בתוויות או בניסוח ברור: Observed, Assessment, Hypothesis. הוסיפו Confidence — גבוה, בינוני או נמוך — והסבירו בקצרה על מה הוא מבוסס.

גם כאשר סוגרים אירוע, תעדו את ההסבר החלופי. “פעילות לגיטימית” אינה מספיקה; כתבו מי אישר, איזה Change קיים, אילו פרטים התאימו ומה היה חריג אך מוסבר.

איך מצטטים לוגים בלי להציף

אין להעתיק עשרות שורות Raw Log לתוך גוף ה-Ticket. בחרו את השדות שמוכיחים את הטענה: Timestamp, Host, User, Process, Parent, Command Line, Source/Destination, Result ו-Event ID. שמרו קישור לחיפוש או לראיה המלאה כאשר המערכת מאפשרת.

כאשר מצטטים Query, תעדו את סביבת הזמן, ה-Data Source והפילטרים. “לא נמצאו אירועים” ללא ציון טווח זמן וטבלה אינו ממצא שניתן לשחזר. כתבו, למשל: “חיפוש SecurityEvent עבור user1 ב-24 השעות שלפני ההתראה לא החזיר Logon מסוג 10 ממכשירים נוספים”.

אל תשנו Raw Evidence כדי שיהיה קריא. ניתן להציג גרסה מסוכמת, אך שמרו את המקור וה-Hash לפי הצורך. מידע רגיש, סודות ו-PII צריכים להישמר בערוץ המאושר ולפי מדיניות הארגון.

איך מתעדים Queries ופעולות

לכל Query משמעותי רשמו מטרה ותוצאה: “מטרה: לבדוק Password Spray. Query: כשלונות לפי Source IP ומשתמש. תוצאה: 37 משתמשים, ללא הצלחה”. רשימה כזאת מונעת חזרות ומראה אילו Hypotheses נבדקו.

בפעולת תגובה ציינו Actor, Time, Approval, Action ו-Outcome. לדוגמה: “10:32 UTC — מנהל IT אישר Disable לחשבון; 10:34 — החשבון הושבת; 10:36 — Refresh Tokens בוטלו; 10:40 — לא נצפו Sessions חדשים”.

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

Ticket חלש מול Ticket מקצועי

רכיב	Ticket חלש	Ticket מקצועי
כותרת	PowerShell alert	PowerShell encoded on FIN-WS17 after anomalous admin login
תקציר	נראה חשוד. לבדוק.	Login חריג לחשבון admin1 ואחריו PowerShell מקודד; התחנה בודדה, Scope בבדיקה.
ראיות	מצורף צילום	Event 4624 + Sysmon 1 + EDR tree; מזהים וקישורים מצורפים.
ניתוח	כנראה וירוס	הרצף תואם Execution; לא נמצא Change; Confidence בינוני עד בדיקת Script.
פעולות	חסמתי	EDR isolate ב-10:28 באישור מנהל משמרת; Token revoke ממתין ל-Identity.
המשך	Tier 2	Tier 2: לפענח Script במעבדה, לבדוק אותו Hash בסביבה ולהרחיב Scope ±24 שעות.

דוגמה מלאה מקוצרת

כותרת: “Successful external login followed by mailbox rule creation — user1”. תקציר: בשעה 07:11 UTC נרשמה התחברות מוצלחת ממדינה שלא נצפתה אצל המשתמש; ארבע דקות לאחר מכן נוצר כלל Mailbox שמעביר הודעות עם המילה “invoice” לתיקייה נסתרת. המשתמש אינו מכיר את הפעילות. החשבון הושבת זמנית והאירוע הוסלם ל-IR.

עובדות: Entra Sign-in מציג Device לא מנוהל ו-MFA satisfied by claim; Audit Log מציג New-InboxRule; לא נמצא Change. ניתוח: הסבר לגיטימי לא זוהה, והפעולה מתאימה להתמדה וגישה לדוא״ל. Confidence גבוה. Scope: חשבון user1; נבדקים Rules, OAuth grants ו-Sessions נוספים. Next step: Revoke sessions, Reset credentials, Review mailbox access והודעה לבעל המידע לפי Playbook.

Checklist מעשי

הכותרת מתארת התנהגות וישות, לא רק שם חוק.
התקציר עונה מה קרה ומה המצב כרגע.
ה-Scope וה-Timeline ברורים.
הפרדתי עובדה, פרשנות והשערה.
ציינתי Queries, טווחי זמן ותוצאות.
תיעדתי Actions, אישור ותוצאה.
הוספתי Classification ונימוק.
יש Next Step עם Owner ויעד זמן.
אין סודות או מידע רגיש בערוץ לא מאושר.

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

לכתוב “בדקתי והכול תקין” ללא ראיות.
להעתיק Raw Logs ארוכים במקום שדות רלוונטיים.
לא לתעד Negative Findings וטווחי חיפוש.
לשנות את הסיפור בדיעבד בלי לציין עדכון.
לסגור Ticket לפני שה-Action אומת.
להשתמש בהשערה ככותרת עובדתית.

סיכום ו-CTA

קחו Ticket ישן או תרחיש מעבדה וכתבו אותו מחדש לפי המבנה שבמאמר. בקשו מאדם שלא השתתף בחקירה לקרוא אותו ולענות: מה קרה, מה הראיות ומה הצעד הבא. בקורס Cybersecurity & AI של HPI מתרגלים חקירה ותיעוד כחלק מעבודת SOC ולא כתרגיל נפרד.

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

האם כותבים את ה-Ticket בסוף החקירה?

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

כמה לוגים צריך לצרף?

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

האם צילום מסך נחשב ראיה?

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

מה ההבדל בין Comment ל-Timeline?

Comment מתעד עדכון או פעולה; Timeline מסדר אירועים מהותיים לפי זמן. לעיתים שניהם נמצאים באותו Case, אך תפקידם שונה.

האם למחוק טעות מה-Ticket?

עדיף לתקן בשקיפות: לציין שההערכה הקודמת השתנתה בעקבות ראיה חדשה. מערכות רבות שומרות Audit Trail בכל מקרה.

מקורות

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

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

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

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

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

על הכותב

תאיר מלכא

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

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

לפרופיל הכותב ↗

הקודם באשכול

מתי אנליסט SOC צריך להסלים אירוע ל-Tier 2 או ל-IR

הבא באשכול

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