סייבר ואבטחת מידע · threat-hunting

MITRE ATT&CK לאנליסט SOC: מיפוי התראה לטכניקה

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

המחשה חזותית מקצועית בנושא MITRE ATT&CK לאנליסט SOC בתחום Threat Hunting וזיהוי

תשובה מהירה

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

Threat Hunting ו-Detection Engineering הופכים ידע על התנהגות יריב לשאלות מדידות, מקורות נתונים וחוקי זיהוי. המטרה אינה לייצר עוד התראות, אלא לשפר כיסוי ואיכות החלטה. המאמר הנוכחי מתמקד ב-MITRE ATT&CK לאנליסט SOC ומיועד ל-אנליסטי SOC ותלמידים. המטרה היא לתת שיטת עבודה שאפשר ליישם בתרגול, בראיון מקצועי ובסביבת עבודה, בלי להסתפק בהגדרה מילונית.

האתגר המרכזי הוא שהנתונים כמעט תמיד חלקיים. tactic, technique/sub-technique, platform יכולים להצביע על כיוון, אך המשמעות שלהם תלויה בזמן, בנכס, במשתמש ובפעילות הצפויה. לכן נבנה את הבדיקה סביב שאלת חקירה, ראיות נדרשות וקריטריון ברור לסיום.

התרחיש המעשי במאמר הוא: מיפוי שלושה אירועים מדומים ל-Techniques.. כל הדוגמאות הן נתוני מעבדה או תיאור תהליכי. כאשר מדובר ב-Penetration Testing, Web או Cloud, יש לעבוד רק עם אישור מפורש, Scope מוגדר ויכולת לעצור את הבדיקה.

מבנה ATT&CK

השדות החשובים אינם בהכרח אלה שמוצגים בראש המסך. ב-MITRE ATT&CK לאנליסט SOC יש לזהות מזהים יציבים, זמן, מקור, יעד, תוצאה והקשר. דוגמאות שימושיות הן tactic, technique/sub-technique, platform, detection strategy, analytic, data component. המטרה היא לאפשר Correlation בין רשומות ולא רק קריאה של Event בודד.

מומלץ ליצור Data dictionary קטן: שם השדה, משמעות, פורמט, מקור, ערכי Null צפויים והאם הוא אמין לקישור. כך ניתן להבדיל בין שדה תצוגה לבין מזהה חקירתי, ולזהות כאשר Connector או גרסה שינו Schema.

מ-Behavior ל-Technique

הנושא 'מ-Behavior ל-Technique' הוא חלק מרכזי בעבודה על MITRE ATT&CK לאנליסט SOC. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את tactic, technique/sub-technique, platform, detection strategy, analytic, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Tactic מול Technique

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

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

Data Sources ו-Detection

הנושא 'Data Sources ו-Detection' הוא חלק מרכזי בעבודה על MITRE ATT&CK לאנליסט SOC. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

תיעוד Confidence ומגבלות

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

מבנה שימושי כולל Summary, Scope, Timeline, Evidence, Impact, Actions, Limitations ו-Next steps. בדוח PT מוסיפים Remediation ו-Retest; בחקירה מוסיפים Containment, Recovery ו-Lessons learned.

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

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: tactic, technique/sub-technique, platform, detection strategy, analytic, data component. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

tactic: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
technique/sub-technique: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
platform: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
detection strategy: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
analytic: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
data component: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

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

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

הגדירו Scope ושאלת עבודה אחת בנושא MITRE ATT&CK לאנליסט SOC.
רשמו את מקורות הנתונים והראיות הדרושים: tactic, technique/sub-technique, platform, detection strategy.
צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

שלב	מה מבצעים	תוצר
הכנה	הגדירו Scope, זמן ויעד. רשמו אילו שדות או ראיות מתוך tactic, technique/sub-technique, platform צפויים להופיע.	תוכנית בדיקה קצרה
יצירת נתון	בצעו פעולה בטוחה ומדומה הקשורה ל-MITRE ATT&CK לאנליסט SOC, ללא מידע אמיתי או השפעה על מערכת ייצור.	אירוע/Request/Flow מבוקר
איסוף	אספו את הראיה הגולמית ואת ההקשר ממקור נוסף. ודאו Time zone, מזהים ושלמות.	שתי ראיות מקושרות
ניתוח	כתבו מה כל ראיה מוכיחה, מה אינה מוכיחה ומהו ההסבר הלגיטימי האפשרי.	מסקנת ביניים
סיום	בחרו סגירה, הסלמה, Finding או Tuning; הוסיפו המלצה ו-Retest.	תוצר מתועד

Checklist מעשי

בדקו ותעדו: Hypothesis.
בדקו ותעדו: טכניקת ATT&CK.
בדקו ותעדו: Data sources.
בדקו ותעדו: Detection logic.
בדקו ותעדו: Expected benign behavior.
בדקו ותעדו: Test cases ו-coverage.
ציינו Time zone, גרסת כלי ושעת איסוף.
שמרו את הנתון הגולמי לפני סינון או שינוי.
כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
הגדירו בעלים ופעולת המשך עם מועד.

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

להתחיל מ-IOC אקראי בלי Hypothesis.
למפות ATT&CK לפי שם בלבד.
לכתוב Rule בלי Test cases.
להתעלם מהתנהגות לגיטימית.
למדוד Rules במקום Coverage.
לא לנהל גרסאות.

סיכום ו-CTA

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

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

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

האם MITRE ATT&CK לאנליסט SOC לבדו מוכיח תקיפה או חולשה?

לא. הוא מספק אות או ממצא שצריך הקשר, אימות ומקור נוסף. מסקנה מקצועית נשענת על רצף ראיות ועל התאמה להתנהגות הצפויה.

מה עושים כאשר חלק מהנתונים חסרים?

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

כמה זמן צריך לשמור את הראיות?

הזמן תלוי במדיניות, רגולציה, עלות וסוג האירוע. חשוב להגדיר מראש Retention, Legal hold ויכולת לייצא ראיה בפורמט שניתן לאמת.

איך מתרגלים בלי לסכן מערכת אמיתית?

משתמשים במכונות וירטואליות, נתונים מדומים, CTF או מעבדה ייעודית. בבדיקות מורשות מגדירים Scope, Stop conditions וגיבוי לפני תחילת העבודה.

מקורות

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

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

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

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

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

על הכותב

תאיר מלכא

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

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

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

הקודם באשכול

IOC מול IOA: מה ההבדל ואיך משתמשים בהם

הבא באשכול

Detection Engineering: איך הופכים התנהגות זדונית לחוק זיהוי