איך חוקרים התראת אבטחה ב-SOC מקצה לקצה

מה מתקבל בהתראה — ומה עדיין חסר

רוב ההתראות מציגות אוסף שדות: שם החוק, חומרה, זמן, משתמש, כתובת IP, שם מחשב ולעיתים טקטיקה או טכניקה של MITRE ATT&CK. השדות האלה חשובים, אך הם תוצר של לוגיקה שנכתבה מראש. לפני שמקבלים את הנרטיב של החוק, צריך להבין מה בדיוק גרם לו לפעול.

פתחו את פרטי החוק וחפשו את תנאי הזיהוי: האם ההתראה נוצרה מאירוע יחיד, מרצף אירועים, מחריגה סטטיסטית או מהתאמה לאינדיקטור מודיעיני? בדקו אילו שדות שימשו את החוק ואילו מהם הגיעו ריקים או עברו נרמול. התראה על “PowerShell חשוד”, לדוגמה, יכולה להישען על שם התהליך בלבד, על שורת פקודה, על תהליך אב, על חיבור רשת או על שילוב ביניהם. עומק החקירה תלוי באיכות האות הראשוני.

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

אימות הנכס, המשתמש ומקור הנתונים

לפני ניתוח ההתנהגות, ודאו שאתם חוקרים את הישות הנכונה. שמות משתמש עשויים להופיע בפורמטים שונים, כתובות IP עשויות להיות כתובות NAT או VPN, ושם מחשב יכול להשתנות לאחר התקנה מחדש. חברו בין מזהים: UPN או SID של המשתמש, מזהה מכשיר, hostname, כתובת IP פנימית וחיצונית, מזהה סשן ומזהה תהליך.

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

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

בניית הקשר ו-Timeline

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

בתרחיש שלנו, התחברות לחשבון ממדינה לא מוכרת בשעה 02:13 היא אירוע ראשון. שתי דקות אחר כך התחנה הארגונית יוצרת תהליך PowerShell עם שורת פקודה מקודדת, ולאחר מכן פונה לדומיין שלא נצפה קודם. הקשר הזה חזק יותר מכל אחד מהאירועים לבדו. עם זאת, עדיין נדרש לבדוק אם המשתמש התחבר דרך VPN, אם צוות IT הפעיל סקריפט תחזוקה, ואם הדומיין שייך לשירות לגיטימי.

רשמו לכל אירוע: זמן מנורמל ל-UTC, מקור, ישויות, פעולה, תוצאה ורמת אמינות. אם קיימת סתירה בין מקורות, אל תעלימו אותה. ציינו אותה והסבירו כיצד היא משפיעה על המסקנה. Timeline אמין מאפשר לזהות את הפעולה הראשונית, את ההתפשטות ואת נקודת העצירה האפשרית.

מיפוי ל-MITRE ATT&CK ובדיקת False Positive

MITRE ATT&CK מספק שפה משותפת לתיאור התנהגות היריב. טקטיקות מתארות את המטרה, וטכניקות מתארות כיצד היא הושגה. בתרחיש שלנו, התחברות באמצעות חשבון גנוב עשויה להיות קשורה לשימוש בחשבונות תקפים, והפעלת PowerShell עשויה להשתייך להפעלת Command and Scripting Interpreter. המיפוי עוזר להבין אילו ראיות נוספות לחפש, אך הוא אינו ציון סיכון ואינו הוכחה לתקיפה.

במקביל חפשו הסבר לגיטימי. האם כתובת המקור היא יציאת VPN מוכרת? האם התהליך חתום ומופעל על ידי מערכת ניהול? האם יש Change Request? האם אותה פעילות מופיעה אצל משתמשים רבים באותו זמן? חשוב להבחין בין False Positive — חוק או נתון שיצרו התראה שגויה — לבין Benign Positive: פעילות שנראית חשודה אך צפויה ומאושרת.

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

החלטה: סגירה, הסלמה או Containment

לאחר איסוף הראיות, סכמו את ההערכה במשפט ברור: “הפעילות תואמת התחברות לא מורשית והפעלת קוד בתחנה”, או “הפעילות נגרמה מסקריפט תחזוקה מאושר דרך כתובת VPN ארגונית”. ציינו את רמת הביטחון ואת העובדות המרכזיות שתומכות בהחלטה.

Containment, כלומר בלימה, נועד לעצור נזק בלי לפגוע שלא לצורך בראיות ובפעילות העסקית. פעולות אפשריות כוללות השעיית חשבון, ביטול סשנים, בידוד תחנה, חסימת דומיין או IP ושימור קבצים ולוגים. אנליסט Tier 1 לא תמיד מוסמך לבצע אותן; עליו לדעת מתי להפעיל Playbook ומתי להסלים לצוות IR, לזהויות, ל-IT או לבעל המערכת.

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

תרחיש מעשי: התחברות חריגה ולאחריה תהליך חשוד

התראה: משתמש בשם dana@company.co.il התחבר ממקור גאוגרפי חריג. לאחר 122 שניות EDR דיווח על powershell.exe עם פרמטר EncodedCommand בתחנה LAP-DANA-17.

שלב 1 — אימות: מאמתים שהחשבון והתחנה משויכים לדנה, שהאירועים אינם כפולים וששני המקורות מסונכרנים בזמן. שלב 2 — הקשר זהות: בודקים MFA, סוג האימות, כתובת IP, User Agent, VPN, מכשיר רשום, ניסיונות כושלים וסשנים נוספים. שלב 3 — הקשר תחנה: בודקים process tree, שורת פקודה, hash, תהליך אב, חיבורי רשת, קבצים חדשים והתראות נוספות.

שלב 4 — קישור: אם מזהה הסשן או זמן ההתחברות מתאים לתחנה, ואם התהליך הופעל בהקשר המשתמש, הקשר מתחזק. שלב 5 — אימות אנושי: לפי הנהלים, יוצרים קשר בערוץ מאומת עם המשתמש או המנהל כדי לבדוק אם הפעילות מוכרת. שלב 6 — החלטה: אם המשתמש מכחיש, ה-MFA חריג והתהליך יצר חיבור לדומיין חשוד, מסלימים ומבצעים בלימה. אם מדובר ב-VPN ובסקריפט IT חתום עם קריאת שינוי, מסווגים כ-Benign Positive ומתעדים.

Checklist מעשי

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

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

• להסתמך על חומרת ההתראה במקום על ההקשר העסקי והראיות.
• לחפש רק בתוך ה-SIEM ולהתעלם מ-EDR, זהויות, DNS או מידע מבעל המערכת.
• לבלבל בין היעדר ראיה לבין ראיה להיעדר.
• לסגור כ-False Positive בלי לתעד Root Cause.
• לבצע בלימה לפני שימור מידע קריטי או ללא סמכות.

סיכום ו-CTA

תרגול חקירה אמיתי דורש שילוב בין לוגים, רשתות, Windows/Linux, SIEM וחשיבה אנליטית. במרכז הידע של HPI ניתן להמשיך למאמר על Triage ב-SOC, ובעמוד קורס Cybersecurity & AI אפשר לראות כיצד התחומים האלה מתחברים למעבדות SOC, חקירת אירועים וניתוח תעבורה.

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

מקורות

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST SP 800-92 — Guide to Computer Security Log Management
• MITRE ATT&CK — Enterprise Tactics
• MITRE ATT&CK — Enterprise Techniques
• Microsoft Learn — Investigate Microsoft Sentinel incidents in depth