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

Playbook ל-SOC: איך בונים תהליך תגובה עקבי להתראה

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

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

תשובה מהירה

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

בכל SOC קיים ידע שלא כתוב בשום מקום: אנליסט מנוסה יודע איזו שאילתה להריץ, למי להתקשר ומתי התראה מסוימת מסוכנת. הבעיה מופיעה במשמרת לילה, בקליטת עובד חדש או בזמן אירוע רחב — כאשר הידע נמצא בראש של אדם שאינו זמין.

Playbook הופך את הידע למסלול עבודה. הוא אינו תסריט קשיח שמחליף שיקול דעת, אלא מסגרת שמבטיחה שהבדיקות הקריטיות לא יישכחו, שהסמכויות ברורות ושכל החלטה מתועדת. Microsoft Sentinel מאפשר ליצור Incident Tasks ידניות או אוטומטיות, ולהשתמש ב-Automation Rules וב-Logic Apps Playbooks כדי להוסיף משימות ולבצע פעולות.

במאמר נבנה Playbook להתראת Impossible Travel. חשוב לזכור שהשם עשוי להתייחס לסוגי זיהוי שונים במוצרי Microsoft: Atypical Travel ו-Impossible Travel הם Risk Detections נפרדים, וחלקם מחושבים Offline ודורשים רישוי מתאים. לכן Playbook חייב להתחיל בהבנת מקור ההתראה ולא בהנחה שכל מוצר מתנהג באותה צורה.

Checklist, Runbook, Playbook ואוטומציה — מה ההבדל

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

אפשר לשלב ביניהם: Playbook של חשבון חשוד מפנה ל-Runbook לביטול סשנים, כולל Checklist ל-Triage ומפעיל אוטומציה להעשרת IP. ההפרדה חשובה משום שלא כל צעד מתאים לאוטומציה, ולא כל הוראת הפעלה צריכה להופיע בגוף תהליך החקירה.

Playbook טוב נכתב עבור מצב מוגדר. “חקירת סייבר” רחב מדי; “Impossible Travel בחשבון עובד” ממוקד מספיק כדי להגדיר קלט והחלטות.

מתי צריך Playbook

יש עדיפות לבניית Playbook כאשר ההתראה נפוצה, הטיפול בה משתנה בין אנליסטים, קיימת פעולה בעלת סיכון, נדרש תיאום עם צוות אחר או שה-SLA קצר. גם אירוע נדיר אך בעל השפעה גבוהה — כמו חשד לפגיעה ב-Domain Admin — מצדיק Playbook.

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

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

מרכיבי Playbook טוב

כותרת ומטרה: מה התרחיש ומה הסיכון. Scope: על אילו מקורות, משתמשים וסביבות הוא חל. Trigger: שם החוק, שדות חובה ותנאי כניסה. Roles: מי מבצע Triage, מי מאשר בלימה ומי מעודכן. Prerequisites: הרשאות, כלים, לוגים ופרטי קשר.

שלבי עבודה: העשרה ראשונית, בדיקות זהות/נכס/רשת, נקודות החלטה, פעולות תגובה, שימור ראיות, תקשורת וסגירה. לכל שלב הגדירו קלט, פעולה, תוצר וקריטריון הצלחה. במקום “בדוק IP”, כתבו “בדוק אם ה-IP שייך ל-VPN ארגוני, ספק ענן, TOR או מקור בעל Reputation שלילי; שמור מקור ותאריך הבדיקה”.

הוסיפו גם Non-goals וגבולות. לדוגמה: Tier 1 אינו משעה חשבון מנהל ללא אישור Incident Commander; Automation אינה סוגרת התראה אם המשתמש Privileged; Playbook אינו מחליף תהליך משפטי לשימור ראיות.

נקודות החלטה ונתיבי הסלמה

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

לכל מסלול קבעו תנאי הסלמה: חשבון Privileged, Token חשוד, MFA לא צפוי, פעילות לאחר ההתחברות, כניסה ממכשיר לא מנוהל או סירוב המשתמש. ציינו למי מסלימים, באיזה ערוץ, אילו נתונים מצרפים ומהו הזמן המרבי.

אל תבנו Playbook שתלוי רק בתגובה של המשתמש. תוקף יכול לענות דרך חשבון שנפרץ. אימות אנושי צריך להיעשות בערוץ חלופי ובהצלבה עם טלמטריה.

ראיות, תיעוד וגרסאות

קבעו אילו ראיות חובה לשמור: מזהי Risk Detection ו-Sign-in, IP, מיקום, מכשיר, Client App, Conditional Access, MFA, User Agent, סשנים, פעולות ענן והתראות קשורות. ציינו פורמט זמן אחיד ואופן שמירת צילומי מסך או exports.

לכל Playbook צריך Version, תאריך, Owner, Change Log ותאריך Review הבא. לאחר שינוי חוק, מקור נתונים או מוצר זהויות, יש לבדוק אם השדות והצעדים עדיין תקפים.

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

דוגמה: Playbook להתראת Impossible Travel

מטרה: להעריך אם שתי פעילויות גאוגרפיות בלתי אפשריות נגרמו מגניבת זהות, VPN/Proxy, שירות ענן או נתוני מיקום לא מדויקים. Trigger: Risk Detection מסוג Impossible Travel או התראה מקבילה, עם משתמש, שני אירועים, זמנים וכתובות מקור.

שלב A — העשרה אוטומטית: משיכת Sign-in Logs, Reputation, שיוך ASN, סטטוס מכשיר, MFA, Conditional Access, Risk State והתראות נוספות. שלב B — Triage: האם החשבון Privileged? האם אחת הכתובות אנונימית או זדונית? האם הפעילות עדיין פעילה? אם כן — הסלמה מיידית.

שלב C — בדיקת הסבר לגיטימי: VPN ארגוני, Secure Web Gateway, טלפון שמחליף רשת, שירות SaaS שפועל בשם המשתמש, או מסד Geo-IP שגוי. שלב D — אימות משתמש בערוץ חלופי: האם ביצע את הפעילות, באילו מכשירים והאם אישר MFA חריג.

שלב E — החלטה: אם שתי הפעילויות מוכרות ומגובה בטלמטריה, סגירה כ-Benign Positive. אם נתון המיקום שגוי, False Positive עקב נתונים. אם המשתמש מכחיש או קיימים Token/Session anomalies, ביטול סשנים, דרישת אימות מחדש, בדיקת פעולות המשך והסלמה ל-IR לפי הרשאה.

שלב F — סגירה ומשוב: תיעוד הראיות, הסיווג, הפעולות והאם נדרש Tuning. אין להחריג משתמש שלם רק משום שהוא נוסע לעיתים קרובות; יש לבחון את מאפייני המקור, המכשיר והאימות.

Checklist מעשי

הגדרתי תרחיש ו-Scope.
ציינתי Trigger ושדות חובה.
הגדרתי Roles וסמכויות.
כל שלב כולל קלט, פעולה ותוצר.
נקודות ההחלטה ברורות.
קיימים נתיבי הסלמה ו-SLA.
הוגדרו ראיות חובה.
קיימים Version, Owner ותאריך Review.
נבדק מה מתאים לאוטומציה ומה דורש אדם.

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

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

סיכום ו-CTA

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

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

האם Playbook חייב להיות אוטומטי?

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

מה ההבדל בין Playbook ל-Runbook?

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

כמה ארוך צריך להיות Playbook?

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

באיזו תדירות לעדכן?

לפחות במועד Review קבוע ולאחר שינוי משמעותי בחוק, מוצר, תשתית, הרשאות או Incident שמצא פער בתהליך.

מה כדאי לאוטומט ראשון?

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

מקורות

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

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

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

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

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

על הכותב

תאיר מלכא

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

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

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

הקודם באשכול

False Positive ב-SOC: איך מזהים, מתעדים ומצמצמים

הבא באשכול

איך בונים Timeline לחקירת אירוע סייבר