שתף באמצעות


שלב 5: פיתוח ובדיקה של מקרי שימוש

חל על:

  • Microsoft Defender XDR

השיטות המומלצות לפריסת Microsoft Defender XDR במרכז פעולות האבטחה (SOC) שלך תלויות בערכת הכלים, התהליכים וערכת הכישורים הנוכחית של צוות SOC. שמירה על היגיינה סייבר בפלטפורמות שונות עשויה להיות מאתגרת בשל כמות הנתונים העצום שמגיעה מעשרות אם לא מאות מקורות אבטחה.

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

פיתוח והגדרה של תהליך מקרה שימוש

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

פעילויות פיקוח SOC הקשורות לפיתוח מקרה שימוש כוללות:

  • דרישות
  • צרכי צוות או הדרכה
  • רשיונות תוכנה
  • חוזי ספק
  • ניהול תוכנית
  • ניהול רישום של מקרה שימוש
  • שמירה/עדכון של תבניות

כדי להקל על תהליכי היצירה של Runbook ו- Playbook, צור עץ החלטות של מקרה שימוש. איור זה מציג דוגמה.

תהליך החלטת מקרה השימוש

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

דוגמה למקרה שימוש 1: משתנה דיוג חדש

השלב הראשון ביצירת מקרה שימוש הוא חלוקה לרמות של זרימת העבודה באמצעות לוח סיפור. הנה דוגמה ללוח סיפור ברמה גבוהה לקבלת הודעה חדשה על ניצול לרעה של דיוג לצוות Threat Intelligence.

זרימת עבודה של מקרה שימוש עבור קמפיין למניעת דיוג

הפעל את זרימת העבודה של מקרה השימוש, לדוגמה 1

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

זרימת עבודה מפורטת של מקרה שימוש עבור קמפיין למניעת דיוג

דוגמה למקרה שימוש 2: סריקת איומים ופגיעות

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

הנה דוגמה של לוח ציור ברמה גבוהה עבור ניהול פגיעויות של Microsoft Defender הנכסים.

זרימת עבודה של מקרה שימוש עבור Threat and Vulnerability Management

הפעל את זרימת העבודה של מקרה השימוש לדוגמה 2

להלן תהליך לדוגמה לסריקת איומים ופגיעות.

זרימת עבודה מפורטת של מקרה שימוש עבור Threat and Vulnerability Management

ניתוח פלט מקרה השימוש והלקחים שלמדת

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

לדוגמה, בתרחיש למניעת דיוג, צוותי SOC עשויים לגלות את הגילויים בטבלה זו.

צוות SOC דרישה אנשים לעמוד בדרישות תהליך לעמוד בדרישות טכנולוגיה רלוונטית זוהה מרווח יומן רישום שינויים של מקרה שימוש פטור (Y/N)
צוות Threat Intelligence and Analytics מקורות נתונים מאכילים כראוי את מנועי בינת האיומים. אנליסט/מהנדס בינת איומים דרישות הזנת נתונים נקבעו, גורמים מפעילים של בינת איומים ממקורות מאושרים Microsoft Defender עבור זהות, Microsoft Defender עבור נקודת קצה צוות Threat Intelligence לא השתמש בקובץ Script לאוטומציה כדי לקשר בין Microsoft Defender XDR API למנגנוןי Intel מאיים הוספת Microsoft Defender XDR כמקורות נתונים למנועי איומים

עדכון חוברת הפעלה של מקרה שימוש

N
צוות ניטור מקורות נתונים מאכילים כראוי את לוחות המחוונים של הניטור Tier 1,2 SOC Analyst-Monitoring & התראות זרימת עבודה לדיווח על ניקוד & מאובטח של מרכז התאימות בדוק התראות Microsoft Defender XDR

ניטור ניקוד מאובטח

אין מנגנון עבור אנליסטי SOC לדווח על זיהוי וריאנט דיוג חדש מוצלח כדי לשפר את Secure Score

הצגת דוחות אבטחה של דואר אלקטרוני בפורטל Microsoft Defender שלך

הוספת תהליך למעקב אחר שיפור ניקוד מאובטח בזרימות עבודה של דיווח N
צוות הנדסה ו- SecOps עדכוני בקרת שינויים בוצעו בספרי ההפעלות של צוות SOC מהנדס SOC ברמה 2 שינוי הליך ההודעה של שליטה עבור לוחות ריצה של צוות SOC שינויים שאושרו במכשירי אבטחה שינויים ב Microsoft Defender XDR הקישוריות לטכנולוגיית האבטחה SOC דורשים אישור הוספת יישומי ענן של Microsoft Defender, Defender for Identity, Defender for Endpoint, Security & Compliance Center ל- SOC runbooks Y

בנוסף, צוותי SOC עשויים לבצע את הגילויים המתוארים בטבלה שלהלן בנוגע לתרחיש ניהול פגיעויות של Defender המתואר לעיל:

צוות SOC דרישה אנשים לעמוד בדרישות תהליך לעמוד בדרישות טכנולוגיה רלוונטית זוהה מרווח יומן רישום שינויים של מקרה שימוש פטור (Y/N)
SOC Oversight כל הנכסים המחוברים לרשתות מאושרות מזוהים ומ לחלק אותם לקטגוריות SOC Oversight, BU owners, application owners, IT asset owners, etc. מערכת ניהול נכסים מרוכזת לגילוי ורשימה של קטגוריות ותכונות של נכסים בהתבסס על סיכונים. ServiceNow או נכסים אחרים.

מלאי מכשירים של Microsoft 365
רק 70% מהרכוש התגלו. Microsoft Defender XDR אחר תיקון יעיל רק עבור נכסים ידועים שירותי ניהול מחזור חיים של נכסים למבוגרים כדי להבטיח Microsoft Defender XDR כיסוי של 100% N
הנדסה & SecOps Teams השפעה גבוהה ופגיעות קריטית ברכוש מותנים בהתאם למדיניות מהנדסי SecOps, אנליסטים של SOC: פגיעות & תאימות, הנדסת אבטחה תהליך מוגדר לקטגוריות של פגיעויות בסיכון גבוה וב קריטי ניהול פגיעויות של Microsoft Defender מחוונים של ניהול פגיעויות של Microsoft Defender Defender for Endpoint זיהה מכשירים בעלי השפעה גבוהה, עם התראה גבוהה ללא תוכנית תיקון או יישום של הפעילות המומלצת של Microsoft הוסף זרימת עבודה כדי להודיע לבעלים של נכסים כאשר נדרשת פעילות תיקון בתוך 30 יום לכל מדיניות; יישם מערכת כרטיסים כדי להודיע לבעלים של הנכס על שלבי תיקון. N
ניטור Teams מצב איומים ופגיעות מדווח דרך פורטל האינטרא-נט של החברה אנליסט Tier 2 SOC דוחות שנוצרו באופן אוטומטי Microsoft Defender XDR מציגים התקדמות תיקון של נכסים בדוק התראות Microsoft Defender XDR

ניטור ניקוד מאובטח

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

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

עדכון פנקסי הפעלות וספרי הפעלות של ייצור

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

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

שימוש במסגרת רגילה להסלמה

Playbooks הם השלבים שעליך לבצע על-ידי צוותי SOC כאשר מתרחש אירוע אמיתי, בהתבסס על השילוב והבדיקה המוצלחת של מקרה השימוש. לכן, חשוב שה- SOC תציית לגישה רשמית לתקריות, כגון NIST Incident Response Standard שהפכה לאחד מהתקנים המובילים בתעשייה לתגובה לתקריות.

תהליך התגובה לתקריות בן ארבעה שלבים של NIST כולל ארבעה שלבים:

  1. הכנה
  2. זיהוי וניתוח
  3. הכלה, מחיקה ושחזור
  4. פעילות לאחר אירוע

דוגמה: מעקב אחר פעילות שלב ההכנה

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

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

מדוע האחריות להסלמה תפורסם? השלב הבא
התראה בניטור SOC מדורגת כפעילה קריטית >של 500/שעה עבור אל Playbook A, Section 2, Activity 5 (עם קישור למקטע playbook)
מסחר אלקטרוני דיווח על התקפה פוטנציאלית של DDoS הפעל את Playbook B-Section C, פעילות 19 (עם קישור למקטע ספר ההשמעה)
מנהל המערכת דיווח על הודעת דואר אלקטרוני חשודה כניסיון דיוג בחנית עבור אל Playbook 5, מקטע 2, פעילות 5 (עם קישור למקטע Playbook)

לאחר ביצוע שלב ההכנה, ארגונים צריכים להפעיל את השלבים הנותרים כמתואר ב- NIST:

  • זיהוי וניתוח
  • הכלה, מחיקה ושחזור
  • פעילות לאחר אירוע

השלב הבא

שלב 6. זיהוי משימות תחזוקה של SOC

עצה

האם ברצונך לקבל מידע נוסף? צור קשר עם קהילת האבטחה של Microsoft בקהילת הטכנולוגיה שלנו: קהילת האבטחה של Microsoft Defender XDR.