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

נתמך ב:

המדריך הזה מיועד למהנדסי אבטחה, למהנדסי SOAR ולמנהלים של מרכזי תפעול אבטחה (SOC) שרוצים לעקוב אחרי תקינות, ביצועים ויעילות האוטומציה של תוכניות הפעולה והשילובים שלהם ב-Google Security Operations. המדריך מסביר איך להשתמש ב-Response Health Hub כדי לזהות, לאבחן ולפתור בעיות שמשפיעות על הפעלת הפלייבוק, על זמן האחזור של הפעולות ועל שילובים עם צד שלישי.

מרכז הבקרה Response Health Hub הוא המקום המרכזי ב-Google SecOps שבו אפשר לעקוב אחרי הסטטוס התפעולי והיעילות של תהליכי העבודה של התגובה האוטומטית בסביבות שונות. הוא מספק תצוגה מקיפה של נפחי ההרצה של תוכניות הפעולה, העומס בתור, שיעורי ההוספה וההרצה מחדש של קבצים מצורפים, זמן האחזור ברמת הפעולה ואבחון של כשלים.

מרכז הבריאות של התגובות כולל את המידע הבא:

  • נפחי הביצוע של המדריך, נפחי העבודה שממתינים בתור ושיעורי ההצלחה של השלמת המדריך
  • שיעורי ההוספה של Playbook וההרצה מחדש (rerun) של Playbook בבקשות תמיכה ובהתראות
  • מדדי זמן האחזור של הפעלת פעולות ומדריכים מקצה לקצה, כולל הפעלות הפעולות והמדריכים האיטיות ביותר
  • מדדי תקינות של פלייבוקים ושילובים, כולל סיכומי פלייבוקים שנכשלו, פלייבוקים שהופסקו, מגמות של כשלים לאורך זמן וסיבות לכשלים בפעולות
  • דירוגים של שילוב וניצול פעולות, שיעורי סגירה אוטומטיים לעומת ידניים והשוואות של זמן ממוצע לפתרון (MTTR)

מונחים חשובים

  • Response Health Hub: הממשק המרכזי ב-Google SecOps למעקב אחרי הסטטוס, זמן האחזור של הביצוע, יעילות האוטומציה והתקינות של פלייבוקים ושילובים.
  • זמן ההפעלה של הפלייבוק: משך הזמן הכולל של הפעלת הפלייבוק, מתחילת התהליך ועד לסופו. הזמן נמדד מהרגע שבו הפלייבוק מופעל בפעם הראשונה ומצורף להתראה או לאירוע, ועד שכל השלבים מסתיימים. משך הזמן הזה כולל ביצוע פעולות, מעברים בין שלבים, עיכובים בתור וזמן המתנה לפעולות ידניות של המשתמש.
  • זמן הביצוע של פעולה: משך הביצוע הפעיל של פעולה ספציפית ב-Playbook, שנמדד מהרגע שבו הפעולה מתחילה לפעול ועד שהתוצאה שלה נשמרת.
  • Playbook מצורף: ‏ Playbook שמופעל ומקושר לכרטיס או להתראה כשההתראה נקלטת או נוצרת.
  • הפעלה מחדש של פלייבוק: הפעלה של פלייבוק שמופעלת מחדש במקרה או בהתראה שבהם הפלייבוק הזה כבר צורף.
  • Faulted: מתאר פעולה של פלייבוק שנתקלה בשגיאה או בזמן קצוב לתפוגה במהלך הביצוע (כמו FAULTED, FAULTED_AND_SKIPPED, UNHANDLED_TIMEDOUT או PENDING_ACTION_TIMEOUT).
  • הופסק: מתאר הרצה של פלייבוק (TERMINATED) שהופסקה באופן ידני על ידי מנתח, או שההתראה או התיק שמשויכים אליה נסגרו לפני שהפלייבוק סיים לפעול.
  • ‫Mean Time to Resolve (MTTR): הזמן הממוצע שחלף, בדקות, מרגע שנוצרה בקשת תמיכה ועד שהיא נסגרה. במרכז הבקרה 'תקינות התגובה' מוצג השוואה בין הזמן הממוצע עד לפתרון (MTTR) של מקרים שנסגרו אוטומטית על ידי תוכניות פעולה (AUTOMATIC) לבין מקרים שנסגרו ידנית על ידי אנליסטים.

לפני שמתחילים

לפני שאתם משתמשים ב-Response Health Hub, ודאו שהוקצה לכם תפקיד שכולל את ההרשאות הנדרשות ב-IAM וב-SOAR כדי לצפות בנתונים של מרכזי הבקרה ושל ה-Playbook. אם אין לכם גישה למרכז לבדיקת תקינות התגובה, פנו לאדמין.

תפקידים רגילים מוגדרים מראש

הגישה לתכונות של Response Health Hub כלולה בתפקידי ה-IAM המוגדרים מראש הבאים:

  • אדמין של Chronicle API ‏ (roles/chronicle.admin)
  • עריכת API של Chronicle ‏ (roles/chronicle.editor)
  • צפייה ב-Chronicle API (roles/chronicle.viewer)

הרשאות ספציפיות ותפקידי SOAR

כדי לצפות ב-Response Health Hub, צריך את הרשאות ה-IAM הבאות ואת הגישה לתפקיד SOAR:

  • הרשאות ה-IAM הנדרשות:
    • ‫chronicle.nativeDashboards.get ו-chronicle.nativeDashboards.list כדי לראות מרכזי בקרה שנבחרו בקפידה
    • ‫chronicle.playbooks.read כדי לראות את מדדי הביצוע והתקינות של הפלייבוק
    • ‫chronicle.nativeDashboards.create ו-chronicle.nativeDashboards.duplicate כדי לשכפל את מרכז הבקרה ולהתאים אותו אישית
  • תפקידים ב-SOAR: המשתמשים צריכים גם תפקיד ב-SOAR עם הרשאות לצפייה ב-playbook ובמרכזי בקרה, כמו אדמין ב-ChronicleSOAR, מנהל איומים ב-ChronicleSOAR, מנהל פגיעויות ב-ChronicleSOAR או צופה ב-ChronicleSOAR. מידע נוסף מופיע במאמר בנושא ניהול הרשאות לשימוש ב-Playbook.

גישה למרכז לבדיקת תקינות התגובה

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

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

סינון של מרכז הבריאות לתגובה

אתם יכולים לצמצם את הנתונים שמוצגים ב-Response Health Hub באמצעות המסננים הבאים ברמת לוח הבקרה, שמופיעים בחלק העליון של הדף:

  • מסנן זמן גלובלי: מסנן את הווידג'טים בלוח הבקרה לפי טווח הזמן שנבחר (ברירת מחדל: Past 7 days).

  • סימולציה של תסריט תגובה: מסנן את מדדי תסריט התגובה לפי השאלה אם ההרצות בוצעו בסימולטור תסריטי התגובה (playbook.simulated). כברירת מחדל, המסנן הזה מוגדר לערך false, כך שבלוח הבקרה מוצגות רק הרצות פעילות של תסריטי תגובה. כדי לבדוק הרצות של סימולציות, מגדירים את המסנן הזה לערך true.

  • מסנן היקף הביצוע: מסנן את המדדים לפי היקף הביצוע של ערכת כללי ההפעלה (playbook.metadata.execution_scope).

  • מסנן סביבות: מסנן את הווידג'טים בלוח הבקרה לפי סביבה אחת או יותר של Google SecOps (playbook.metadata.environments ו-case.environment). כברירת מחדל, המסנן הזה מוגדר ל-Default Environment ואפשר לבחור כמה סביבות בו-זמנית.

הסבר על הממשק של Response Health Hub ושימוש בו

כאן מוסבר על הקטעים והווידג'טים ב-Response Health Hub, כדי שתוכלו לעקוב אחרי הביצועים של הפלייבוקים ולזהות בעיות בתהליכי העבודה ב-SOAR.

מרכז הבריאות של התגובה מאורגן לפי הקטעים הבאים:

נפח ושיעור אימוץ

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

  • סה"כ הפעלות של פלייבוקים: ווידג'ט עם מספר גדול שמציג את המספר הכולל של הפעלות הפלייבוקים שבוצעו במסגרת הזמן שנבחרה.
  • 30 הפלייבוקים שהופעלו הכי הרבה: תרשים עמודות אופקי שמדרג את 30 הפלייבוקים המובילים לפי מספר ההפעלות הכולל במסגרת הזמן שנבחרה.
  • ‫Playbooks Pending in Queue: ווידג'ט עם מספר גדול שמציג את המספר הנוכחי של הפעלות הפלייבוקים בסטטוס PENDING_IN_QUEUE שנמצאות בתור וממתינות להפעלה.
  • שיעור ההצלחה של הפעלת הפלייבוק: תרשים עוגה שמציג את ההתפלגות של הפעלות הפלייבוק שהסתיימו, לפי סטטוס (COMPLETED לעומת FAILED).
  • נפח ההרצה היומי של תוכנית הפעולה: תרשים קו שמציג את המגמה היומית של סך ההרצות של תוכניות הפעולה לאורך זמן, מקובצות לפי שם התצוגה של תוכנית הפעולה.

שיעורי הצירוף של פלייבוקים

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

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

זמן ביצוע התגובה

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

  • משך הביצוע הממוצע של Playbook: ווידג'ט עם מספר גדול שמציג את משך הזמן הממוצע מקצה לקצה (Xh Ym Zs) של הפעלות Playbook שהושלמו, מהטריגר הראשוני והצירוף ועד שכל השלבים מסתיימים. הנתונים האלה כוללים את זמן הביצוע של הפעולה, מעברים בין שלבים, עיכובים בתור וזמן המתנה ידני של המשתמש.
  • זמן ביצוע ממוצע לפי פלייבוק: תרשים עמודות שמציג את משך הביצוע הממוצע, בשניות, לכל פלייבוק.
  • זמן ביצוע ממוצע של פעולה: ווידג'ט עם מספר גדול שמציג את משך הביצוע הפעיל הממוצע (Xh Ym Zs) של פעולות בודדות בפלייבוק, שנמדד מהרגע שבו הפעולה מתחילה להתבצע ועד שהתוצאה שלה נשמרת.
  • זמן ביצוע ממוצע לפי פעולה: תרשים עמודות שבו מוצג משך הביצוע הממוצע, בשניות, לכל פעולה (לא כולל סמני לולאה פנימיים ForEachStartLoop ו-ForEachEndLoop).
  • Top 30 Slowest Playbook Executions: Lists the 30 longest individual playbook runs.
  • ‫Top 30 Slowest Action Executions: רשימה של 30 הפעולות הבודדות שההרצה שלהן נמשכה הכי הרבה זמן.

תקינות הפלייבוק

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

  • סיכום של 30 ההפעלות האחרונות של Playbook שנכשלו: רשימה של 30 ההפעלות האחרונות של Playbook שנכשלו (FAILED), לצד הפעולה הספציפית שנכשלה (FAULTED) והודעת השגיאה.
  • ‫Top 30 Failure Rate Playbooks: דירוג של 30 הפלייבוקים עם המספר הגבוה ביותר של הרצות שנכשלו ואחוזי הכישלון שלהם.
  • ‫Top 30 Playbooks Terminated: מעקב אחרי פלייבוקים עם האחוז הגבוה ביותר של הרצות TERMINATED.
  • ‫Failed Playbooks % Over Time: תרשים קו שמציג את המגמה היומית של אחוזי הכישלונות של הפלייבוקים, מקובצים לפי שם הפלייבוק.
  • אחוז השילובים שנכשלו לאורך זמן: תרשים קו שבו מוצגת המגמה היומית של אחוז הפעולות שנכשלו (פעולות FAULTED), מקובצות לפי שילוב.
  • שיעור הכשלים בפעולות: פירוט של מספר הכשלים בפעולות, שיעורי הכשלים, סטטוס הכשלים והודעות השגיאה האחרונות לכל שילוב ופעולה.

שימוש בשילובים ויעילות האוטומציה

בקטעים Integrations Utilization ו-Automation Effectiveness מודגש באילו כלים הפלייבוקים שלכם משתמשים הכי הרבה, ומכומתת ההשפעה התפעולית של האוטומציה על זמני הסגירה והפתרון של מקרים:

  • 30 השילובים הנפוצים ביותר: תרשים עמודות שמדרג את 30 השילובים המובילים לפי סך הביצועים של הפעולות בכל תוכניות הפעולה (לא כולל שלבים פנימיים של Loop).
  • ‫30 הפעולות הכי נפוצות: תרשים עמודות שמדרג את 30 הפעולות הנפוצות ביותר לפי מספר ההפעלות בכל הפלייבוקים (לא כולל ForEachStartLoop ו-ForEachEndLoop).
  • שיטת סגירת הפנייה או ההתראה (אוטומטית לעומת ידנית): תרשים טבעת שמציג את היחס בין הפניות שנסגרו (CLOSED) ונפתרו באופן אוטומטי על ידי פלייבוקים (AUTOMATIC) לבין פניות שנסגרו באופן ידני על ידי מנתחי SOC.
  • ‫Case MTTR: Automated vs. Manual Closure: תרשים עמודות שמשווה בין הזמן הממוצע לפתרון (MTTR, בדקות בסולם לוגריתמי) של בקשות תמיכה שנסגרו באופן אוטומטי על ידי פלייבוקים, לבין בקשות תמיכה שנסגרו באופן ידני.

זיהוי וחקירה של בעיות בפלייבוקים ובשילובים

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

בדיקת הפעלות של פלייבוקים שנכשלו ופעולות שגויות

אם בתרשים שיעור ההצלחה של הפעלת Playbook או בתרשים אחוז ה-Playbook שנכשלו לאורך זמן מצוינת עלייה במספר הכשלים ב-Playbook, צריך לבצע את הפעולות הבאות:

  1. עוברים אל Top 30 Failure Rate Playbooks כדי לזהות לאילו פלייבוקים יש את מספר הכשלונות הגבוה ביותר ואת אחוזי הכשלונות הגבוהים ביותר.
  2. כדי לדעת אם הכשלים התחילו פתאום (לדוגמה, אחרי עריכה של playbook או אחרי שתוקף האישורים פג) או שהם מייצגים בעיה מתמשכת, אפשר לעיין בתרשים הקו Failed Playbooks % Over Time.
  3. בקטע Latest 30 Failed Playbook Summary, מאתרים את ההפעלות האחרונות של הפלייבוק שנכשל ובודקים את השדות Action,‏ Action Status ו-Action Message כדי לראות את השלב המדויק ואת הודעת השגיאה שגרמו לפלייבוק להיכשל.
  4. לוחצים על הקישור Case ID (מספר הפנייה) בקטע Latest 30 Failed Playbook Summary (סיכום של 30 הפלייבוקים האחרונים שנכשלו) כדי לפתוח את הפנייה הרלוונטית בכרטיסייה חדשה.
  5. בדף Cases, בוחרים את ההתראה, פותחים את הכרטיסייה Playbooks ולוחצים על שם הפלייבוק כדי לפתוח את חלונית הסיכום של הפלייבוק. בקטע Errors בחלונית, אתם יכולים לבדוק את היומנים המלאים של השלבים ולהפעיל מחדש את הפעולה שנכשלה או את כל הפלייבוק אחרי שתטפלו בשורש הבעיה.

אבחון של שגיאות שילוב, שגיאות פעולה או פסק זמן

אם כמה תוכניות הפעלה נכשלות בו-זמנית, לרוב הסיבה לכך היא בעיה משותפת בשילוב עם צד שלישי (למשל, אישורי API שפג תוקפם, בעיות בקישוריות לרשת או הגבלת קצב). כדי לבודד בעיות ברמת השילוב:

  1. בודקים את התרשים Failed Integrations % Over Time (אחוז השילובים שנכשלו לאורך זמן) כדי לראות אם יש קשר בין העליות החדות בשיעור הכשלים לבין שילוב ספציפי בחוברות ההפעלה.
  2. בתצוגה Actions Failure Rate (שיעור הכשלים בפעולות), מאתרים את השילוב המושפע ובודקים את Failure % (שיעור הכשלים), Failure Statuses (סטטוסי הכשלים) ו-Latest Failure Reasons (הסיבות האחרונות לכשלים):
    • ‫FAULTED או FAULTED_AND_SKIPPED: מציין שהפעולה החזירה שגיאת הרצה. כדאי לעיין בקטע סיבות לכישלון האחרון כדי לקבל פרטים כמו 401 Unauthorized, 403 Forbidden או פרמטרים לא תקינים של קלט.
    • ‫UNHANDLED_TIMEDOUT: מציין שהזמן הקצוב לתפוגה של הפעולה או של הסוכן המרוחק חלף לפני שהביצוע הסתיים.
    • ‫PENDING_ACTION_TIMEOUT: מציין שפעולה ממתינה אסינכרונית או ידנית חרגה מהזמן הקצוב לתפוגה שהוגדר לה לפני קבלת תגובה.
  3. עוברים אל Response > IDE או Settings > SOAR Settings > Environments כדי לאמת ולבדוק את ההגדרות האישיות ופרטי הכניסה של מופע השילוב בסביבה המושפעת.

בדיקת עיכובים בהפעלת Playbook וגיבויים בתור

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

  1. בדיקת הצטברות של פלייבוקים בתור: בקטע נפח ושימוש, מעיינים בווידג'ט פלייבוקים בהמתנה בתור. מספר גבוה של ספרי הפעלה בתור מצביע על כך שהתראות נכנסות מפעילות ספרי הפעלה מהר יותר מהקצב שבו הם מסיימים את ההרצה.
  2. השוואה בין זמן הביצוע של הפלייבוק לזמן הביצוע של הפעולה:
    • בקטע זמן ביצוע התגובה, משווים בין זמן הביצוע הממוצע של הפלייבוק לבין זמן הביצוע הממוצע של הפעולה.
    • פעולות שילוב איטיות: אם הערך של זמן הביצוע הממוצע של פעולה גבוה, כדאי לעיין בתרשים זמן הביצוע הממוצע לפי פעולה ובטבלה 30 פעולות השילוב עם זמן הביצוע הכי ארוך כדי לזהות אילו פעולות שילוב ספציפיות לוקחות הכי הרבה זמן לביצוע. לוחצים על הקישור מספר הפנייה כדי לבדוק את הפנייה הספציפית ואת ההתראה שבה הפעולה האיטית הופעלה.
    • זמני המתנה או עיכובים בדגימה בתהליך העבודה: אם הערך של זמן הביצוע הממוצע של Playbook גבוה אבל הערך של זמן הביצוע הממוצע של פעולה נשאר נמוך, העיכוב מתרחש בין ביצועי פעולות פעילים. בדרך כלל זה קורה כי פלייבוקים ממתינים לשלבי אישור ידניים של מנתח נתונים, לפעולות אסינכרוניות בהמתנה או לעיכובים בתור. בודקים את Avg Execution Time by Playbook ואת Top 30 Slowest Playbook Executions כדי לאתר את ההפעלות של הפלייבוק שהושפעו.

אופטימיזציה של טריגרים, הפעלות חוזרות והפעלות שהסתיימו ב-Playbook

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

  1. בדיקת הקובץ המצורף והרצה חוזרת של הספירות:
    • בקטע Playbook Attachment Rates, מעיינים בווידג'טים Avg Playbooks Attached per Case / Alert ו-Max Playbooks Attached per Case / Alert.
    • בודקים את הקבצים המצורפים המובילים של Playbook / הפעלות חוזרות. ערך גבוה בעמודה מספר ההפעלות מחדש ביחס לעמודה מספר הפעמים שצורף יכול להצביע על כך שמנתחי נתונים מפעילים שוב ושוב פלייבוק בגלל כשלים זמניים בפעולות או נתוני העשרה חלקיים.
  2. בדיקת פלייבוקים שהופסקו:
    • מעיינים ב30 המדריכים המובילים שהופסקו בקטע תקינות המדריך.
    • פלייבוקים מסומנים בסטטוס TERMINATED כשאנליסט עוצר את הפלייבוק באופן ידני, או כשההתראה או האירוע הבסיסיים נסגרים לפני שהפלייבוק מסיים לפעול. אם לפלייבוק יש אחוז סגירה גבוה, צריך לבדוק אם כלל סגירה אוטומטי או פלייבוק אחר סוגרים את ההתראה לפני ששלבי ההעשרה או ההכלה הארוכים מסתיימים.

הערכת היעילות של האוטומציה של SOC ו-MTTR

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

  1. בקטע Automation Effectiveness, בודקים את תרשים הטבעת Case / Alert Closure Method (Auto vs. Manual) כדי לעקוב אחרי שיעור בקשות התמיכה שנסגרו ונפתרו באופן אוטומטי (AUTOMATIC) לעומת באופן ידני.
  2. בודקים את תרשים העמודות Case MTTR: Automated vs. Manual Closure (הזמן הממוצע עד לפתרון בעיה: סגירה אוטומטית לעומת סגירה ידנית) כדי להשוות בין הזמן הממוצע לפתרון בעיה בדקות, בין סגירות אוטומטיות לסגירות ידניות.
  3. אפשר להשתמש במסנן הסביבות כדי להשוות בין שיעורי הסגירה האוטומטית וזמן התיקון הממוצע (MTTR) בסביבות או בדיירים שונים, ולזהות סביבות שבהן פלייבוקים נוספים של מיון אוטומטי או סגירה אוטומטית יכולים לצמצם את זמן הטיפול הידני של האנליסטים.

תיקון עצמי של בעיות תקינות בשילוב וב-Playbook

כדי לפתור בעיות נפוצות בפלייבוקים ובשילובים שזוהו ב-Response Health Hub, כדאי לעיין בתסמינים, בסיבות ובפתרונות המוצעים הבאים:

  • סטטוס הפעולה הוא FAULTED או FAULTED_AND_SKIPPED עם שגיאות אימות (401 / 403):
    • הסיבה: פג התוקף של מפתח ה-API, הטוקן או חשבון השירות שהוגדרו למכונה של השילוב, או שאין להם את ההרשאות הנדרשות.
    • הצעות לתיקון: בודקים את הסיבות האחרונות לכשלים בווידג'ט שיעור הכשלים בפעולות כדי לזהות את השילוב, מעדכנים את פרטי הכניסה בהגדרות השילוב בסביבה המושפעת ובודקים את הקישוריות.
  • סטטוס הפעולה הוא UNHANDLED_TIMEDOUT:
    • הסיבה: זמן התגובה של נקודת הקצה של הצד השלישי היה ארוך מדי, או שהיו בעיות בקישוריות או במשאבים של הנציג המרוחק שמבצע את הפעולה.
    • המלצות לפתרון: אם השילוב פועל מרחוק, כדאי לבדוק את תקינות שירות היעד ולפתור בעיות בסוכנים מרוחקים. כדאי להגדיל את זמן הקצוב לתפוגה של הפעולה או לצמצם את היקף השאילתה שמועברת לפעולה.
  • סטטוס הפעולה הוא PENDING_ACTION_TIMEOUT:
    • הסיבה: שלב בפלייבוק שממתין לקלט של משתמשים או קריאה חוזרת (callback) אסינכרונית חיצונית לא הושלמו לפני שנגמר הזמן הקצוב לתפוגה של השלב.
    • הצעות לתיקון: לוחצים על מספר פנייה בווידג'ט Latest 30 Failed Playbook Summary כדי לבדוק את השלב בהמתנה. משנים את הגדרות הזמן הקצוב לתפוגה של השלב בכלי לעיצוב תוכניות הפעולה, או מגדירים ענפים חלופיים לפעולות בהמתנה שהזמן הקצוב לתפוגה שלהן הסתיים.
  • High Percentage Terminated (TERMINATED) in Top 30 Playbooks Terminated:
    • הסיבה: מקרים או התראות נסגרים (באופן ידני או על ידי כלל אוטומציה אחר) בזמן שספר ההפעלה עדיין פועל, או שאנליסטים עוצרים את ספר ההפעלה באופן ידני.
    • המלצה לתיקון: בודקים את משך ההפעלה של ספר ההפעלה במשך ההפעלה הממוצע לפי ספר הפעלה ומוודאים ששלבי הסגירה האוטומטית של הכרטיס מתרחשים רק אחרי שכל פעולות ההעשרה והתגובה הנדרשות מסתיימות.
  • מספר גבוה של תוכניות פעולה בהמתנה בתור (PENDING_IN_QUEUE):
    • הסיבה: עלייה חדה במספר ההתראות או טריגרים רחבים מדי של תוכנית הפעולה גורמים להוספה לתור של יותר הרצות של תוכנית הפעולה מכפי שצינור הביצוע יכול לעבד בו-זמנית.
    • הצעות לתיקון: כדאי לשפר את התנאים להפעלת הפלייבוק כדי שיהיו סלקטיביים יותר, לאחד פלייבוקים מיותרים באמצעות בלוקים לשימוש חוזר ולבדוק את הפעולות והמסננים בכמות גדולה בפלייבוקים.
  • משך הביצוע הממוצע של מדריך הפעלה גבוה בהרבה ממשך הביצוע הממוצע של פעולה:
    • הסיבה: פלייבוקים מבלים את רוב מחזור החיים שלהם בהמתנה לפעולות ידניות של משתמשים או לקריאות חוזרות (callbacks) חיצוניות, במקום לבצע באופן פעיל פעולות שילוב.
    • הצעה לתיקון: כדאי לבדוק את 30 ההפעלות האיטיות ביותר של Playbook כדי לזהות אילו Playbook ממתינים להתערבות ידנית, ולהפוך לאוטומטיות החלטות שגרתיות לגבי אישור או תעדוף, במקרים המתאימים.

אחרי שאתם משנים את הפלייבוקים או את הגדרות השילוב, עקבו אחרי התרשימים Failed Playbooks % Over Time (אחוז הפלייבוקים שנכשלו לאורך זמן) ו-Failed Integrations % Over Time (אחוז השילובים שנכשלו לאורך זמן) ב-Response Health Hub כדי לוודא ששיעורי הכישלונות חוזרים לרמות הצפויות.

פתרון בעיות

בטבלה הבאה מוסבר על התנהגויות של הממשק של Response Health Hub שאתם עשויים להיתקל בהן כשאתם מנתחים את הנתונים:

  • הערך של Playbooks Pending in Queue לא משתנה כשמתאימים את Global Time Filter: הווידג'ט Playbooks Pending in Queue מודד את צבר המשימות הפעיל הנוכחי (PENDING_IN_QUEUE) בחלון זמן קבוע של 7 ימים, ומתעלם בכוונה מ-Global Time Filter כדי שתמיד תוכלו לראות את סטטוס התור בזמן אמת.
  • כברירת מחדל, לא מוצגים הפעלות של סימולציות של תוכניות פעולה: המסנן Playbook Simulated מוגדר כברירת מחדל לערך false, כדי שהפעלות בדיקה מסימולטור תוכניות הפעולה לא ישפיעו על מדדי תקינות הייצור. כדי לפתור בעיות בהרצות סימולציה, משנים את Playbook Simulated ל-true.
  • פעולות לולאה והשילוב של Loop לא מופיעים בתרשימים של הפעולות או השילובים המובילים: שלבי בקרה פנימיים של לולאות (ForEachStartLoop,‏ ForEachEndLoop והשילוב של Loop) מוחרגים באופן אוטומטי מהתרשימים Avg Execution Time by Action,‏ Top 30 Most Frequently Used Integrations ו-Top 30 Most Frequently Used Actions, כדי שהדירוגים ישקפו את השילובים והפעולות בפועל שקשורים לאבטחה.
  • ההבדל בין זמן הביצוע הממוצע של הפלייבוק לזמן הביצוע הממוצע של הפעולה: זמן הביצוע הממוצע של הפלייבוק מודד את משך הזמן הכולל של הפלייבוק מההתחלה ועד הסוף (playbook.end_time פחות playbook.start_time), ואילו זמן הביצוע הממוצע של הפעולה מחשב את הממוצע של זמן הריצה הפעיל (playbook.action.execution_time_ms) של פעולות ספציפיות. אם פלייבוק ממתין כמה שעות עד שאנליסט יאשר פעולה בהמתנה, זמן הביצוע שלו יהיה ארוך, גם אם הפעולות האוטומטיות שלו מסתיימות תוך כמה שניות.

המאמרים הבאים

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.