פיתוח תוספים לניתוח (parser)

נתמך ב:

במסמך הזה מוסבר איך ליצור תוספים למנתח כדי לחלץ שדות מנתוני יומן גולמיים ולמפות אותם לשדות UDM (מודל נתונים מאוחד) של היעד בפלטפורמת Google Security Operations.

המסמך מתאר את תהליך היצירה של תוסף המנתח:

יצירת תוספי מנתח

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

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

תהליך החילוץ והנורמליזציה של המנתח

‫Google SecOps מקבל נתוני יומנים מקוריים בתור יומנים גולמיים. מנתחים שמוגדרים כברירת מחדל (ומותאמים אישית) מחלצים שדות ליבה של יומנים ומנרמלים אותם לשדות UDM מובְנים ברשומות UDM. הנתונים האלה מייצגים רק קבוצת משנה של נתוני היומן הגולמיים המקוריים. אתם יכולים להגדיר תוספי מנתחי נתונים כדי לחלץ ערכי יומן שלא מטופלים על ידי מנתחי הנתונים שמוגדרים כברירת מחדל. אחרי שמפעילים את התוספים לניתוח, הם הופכים לחלק מתהליך חילוץ הנתונים והנורמליזציה של Google SecOps.

תהליך העבודה של הטמעה ונורמליזציה

הגדרת תוספי מנתח חדשים

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

  • גישה בלי צורך בתכנות

    הגישה ללא קוד מתאימה במיוחד לחילוצים פשוטים מיומנים גולמיים בפורמט מקורי של JSON,‏ XML או CSV. הוא מאפשר לציין שדות של מקור יומן גולמי ולמפות שדות UDM תואמים של יעד.

    לדוגמה, כדי לחלץ נתוני יומן בפורמט JSON עם עד 10 שדות, באמצעות השוואות שוויון פשוטות.

  • גישת קטע הקוד

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

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

    • חילוץ נתונים מורכבים או לוגיקה מורכבת.
    • נתונים לא מובנים שדורשים מנתחי נתונים שמבוססים על Grok.
    • פורמטים שהם לא JSON, כמו CSV ו-XML.

    קטעי הקוד משתמשים בפונקציות כדי לחלץ נתונים ספציפיים מנתוני היומן הגולמיים. לדוגמה, Grok,‏ JSON,‏ KV ו-XML.

    ברוב המקרים, הכי טוב להשתמש בגישה למיפוי נתונים שבה השתמשו במנתח ברירת המחדל (או במנתח בהתאמה אישית).

מיזוג ערכים חדשים שחולצו לשדות UDM

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

  • החלפת ערכים קיימים: הערכים שחולצו מחליפים את הערכים הקיימים בשדות היעד של ה-UDM.

    החריג היחיד הוא שדות חוזרים, שבהם אפשר להגדיר את תוסף המנתח כך שיוסיף ערכים חדשים כשכותבים נתונים בשדה חוזר ברשומת ה-UDM.

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

    לדוגמה, אם המנתח שמוגדר כברירת מחדל ממפה שדה של יומן גולמי לשדה ה-UDM‏ event.metadata.description, והרחבת המנתח ממפה שדה אחר של יומן גולמי לאותו שדה UDM, הרחבת המנתח מחליפה את הערך שהוגדר על ידי המנתח שמוגדר כברירת מחדל.

בורר שדות חוזרים

בשתי הגישות, מיפוי שדות נתונים (בלי צורך בתכנות) וכתיבת קטע קוד, אתם יכולים לקבוע איך תוסף הניתוח ישמור ערכים בשדות חוזרים (שדות שתומכים במערך של ערכים, למשל principal.ip). בחלונית Extension (הגדרת התוסף), משתמשים בשדה Repeated Fields, שמציע את האפשרויות Append Values ו-Replace Values.

התנהגות של הוספה לעומת החלפה

בחלק מהשדות של UDM מאוחסן מערך של ערכים, כמו השדה principal.ip. הבורר Repeated Fields מאפשר לכם לקבוע איך תוסף הניתוח יאחסן נתונים חדשים שחולצו בשדה חוזר:

  • הוספת ערכים:

    תוסף המנתח יוסיף את הערך החדש שחולץ למערך של הערכים הקיימים בשדה ה-UDM.

  • החלפת ערכים:

    תוסף המנתח יחליף את מערך הערכים הקיימים בשדה ה-UDM בערך החדש שחולץ.

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

  • אפשר למפות ערכים ל-udm.principal.ip כי השדה החוזר ip נמצא ברמה הנמוכה ביותר בהיררכיה, ו-principal הוא לא שדה חוזר.
  • אי אפשר למפות ערכים אל udm.intermediary.hostname כי intermediary הוא שדה חוזר, והוא לא נמצא ברמה הנמוכה ביותר בהיררכיה.

בטבלה הבאה מוצגות דוגמאות לאופן שבו ההגדרה של בורר השדות החוזרים משפיעה על רשומת ה-UDM שנוצרת.

בחירת שדות חוזרים יומן לדוגמה הגדרת תוסף המנתח תוצאה שנוצרה
הוספת ערכים {"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":""},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}} שדה תנאי מקדים: protoPayload.requestMetadata.callerIp
ערך תנאי מקדים: " "
אופרטור תנאי מקדים: NOT_EQUALS
שדה נתונים גולמיים: protoPayload.requestMetadata.callerIp
שדה יעד: event.idm.read_only_udm.principal.ip 		metadata:{event_timestamp:{}.....}principal:{Ip:"1.1.1.1, 2.2.2.2"} } }
הוספת ערכים {"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":""},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}} תנאי מוקדם 1:
שדה התנאי המוקדם:protoPayload.requestMetadata.callerIp
ערך התנאי המוקדם: " "
אופרטור התנאי המוקדם: NOT_EQUALS
שדה הנתונים הגולמיים: protoPayload.requestMetadata.callerIp
שדה היעד: event.idm.read_only_udm.principal.ip

תנאי מוקדם 2:
שדה נתונים גולמיים: protoPayload.requestMetadata.name
שדה יעד: event.idm.read_only_udm.metadata.product_name

 אירועים שנוצרו על ידי מנתח מובנה לפני החלת התוסף.
metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}

הפלט אחרי החלת התוסף.
timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} .... product_name: "Akamai Ltd"}principal:{ip:"1.1.1.1, 2.2.2.2, 3.3.3.3"}}}

החלפת ערכים {"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":""},"requestMetadata":{"callerIp":"2.2.2.2"}}} שדה תנאי מקדים: protoPayload.authenticationInfo.principalEmail
ערך תנאי מקדים: " "
אופרטור תנאי מקדים: NOT_EQUALS
שדה נתונים גולמיים: protoPayload.authenticationInfo.principalEmail
שדה יעד: event.idm.read_only_udm.principal.ip 		אירועי UDM שנוצרו על ידי מנתח מובנה לפני החלת התוסף.
timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}

פלט UDM אחרי החלת התוסף timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ....} principal:{ip:"2.2.2.2"}}}

מגבלות

  • תוסף אחד לניתוח לכל סוג של יומן: אפשר ליצור רק תוסף אחד לניתוח לכל סוג של יומן.
  • גישה אחת בלבד להוראות למיפוי נתונים: אתם יכולים ליצור תוסף למנתח באמצעות הגישה בלי צורך בתכנות או באמצעות הגישה של קטע קוד, אבל לא את שתי הגישות ביחד.
  • דוגמאות של יומנים לאימות: כדי לאמת תוסף של מנתח UDM, צריך דוגמאות של יומנים מ-30 הימים האחרונים. פרטים נוספים זמינים במאמר איך מוודאים שיש מנתח פעיל לסוג היומן.
  • שגיאות בניתוח בסיסי: אי אפשר לזהות או לתקן שגיאות בניתוח בסיסי בתוך תוספי מנתח.
  • טיפול בשדות חוזרים: אפשר להשתמש רק בשיטה אחת (הוספה או החלפה) בתוסף ספציפי. כדי למנוע אובדן נתונים לא מכוון, חשוב להיזהר כשמחליפים אובייקטים חוזרים שלמים.
  • ‫Additional.fields מפורש כקבוצה של צמדי מפתח/ערך, ולא כשדה חוזר: לכן, אפשר לשלב בצורה חלקה גם את מיפויי ה-UDM של המנתח וגם את פלטי ה-UDM של התוסף על ידי הוספת צמדי המפתח/ערך המתאימים שלהם לקבוצה.
  • אירועים שהופגה בהם העמימות: תוספי מנתח לא יכולים לטפל ביומנים עם כמה אירועים ייחודיים ברשומה אחת, למשל מערך של Google Drive.
  • XML ובלי צורך בתכנות: מצב בלי צורך בתכנות לא נתמך ב-XML. במקום זאת, השתמשו בשיטה של קטע הקוד.
  • תחביר מנתח לעומת כללי זיהוי של YARA-L: מנתחי הטמעה ותוספים של מנתחים משתמשים ב-Logstash Grok ובתחביר הגדרה עם מסננים (לדוגמה, grok,‏ mutate,‏ json,‏ date ו-base64) בזמן ההטמעה כדי לנתח יומנים גולמיים למודל הנתונים המאוחד (UDM). מנתחי נתונים לא יכולים להשתמש בתחביר YARA-L, בבלוקים של תוצאות או בפונקציות של מחוללים (כמו yield). YARA-L 2.0 היא שפת שאילתות של מנוע זיהוי בלבד, שמוערכת בהמשך התהליך באירועי UDM מנורמלים לצורך התרעה על איומים, והיא לא יכולה לנתח יומנים גולמיים, לשנות שדות UDM או להשמיט תנועה נכנסת של יומנים.
  • החלה רק על יומנים חדשים כברירת מחדל: כברירת מחדל, תוספי הניתוח חלים על יומנים חדשים שנוספו רק מרגע ההפעלה. אם יש צורך עסקי קריטי לנתח מחדש יומנים היסטוריים עם מיפויים מעודכנים, אתם יכולים לבקש משימת הפעלה מחדש של יומן בקצה העורפי דרך התמיכה של Google Cloud . מידע נוסף זמין במאמר ניתוח מחדש של נתונים היסטוריים (הפעלה מחדש של יומן).
  • תוויות הטמעה לא נגישות בלוגיקה של המנתח: תוספי מנתח לא יכולים לקרוא תוויות הטמעה (metadata.ingestion_labels) כדי למפות ערכים לשדות UDM, כי המנתחים פועלים בסביבת הרצה בארגז חול עם הרשאות גישה לגוף היומן הגולמי בלבד.
  • מילות מפתח שמורות בגישה בלי צורך בתכנות: אם היומנים מכילים אחת ממילות המפתח השמורות הבאות, השתמשו בגישה של קטע הקוד במקום בגישה בלי צורך בתכנות:
    • collectionTimestamp
    • createTimestamp
    • enableCbnForLoop
    • event
    • filename
    • message
    • namespace
    • output
    • onErrorCount
    • timestamp
    • timezone
  • הסרת מיפויים קיימים: אתם יכולים להסיר מיפויים קיימים של שדות UDM רק באמצעות קטע הקוד.
  • אי אפשר להסיר מיפוי של שדה UDM של שם מארח באמצעות תוסף: אי אפשר לבטל (להסיר) מיפוי של שדה UDM של שם מארח (לדוגמה, principal.hostname) באמצעות תוסף.

מושגים שקשורים למנתח

במסמכים הבאים מוסברים מושגים חשובים שקשורים למנתחים:

דרישות מוקדמות

דרישות מוקדמות ליצירת תוסף לניתוח:

  • חייב להיות מנתח פעיל כברירת מחדל (או מותאם אישית) לסוג היומן.
  • ‫Google SecOps צריך להיות מסוגל להטמיע ולנרמל את היומנים הגולמיים באמצעות מנתח ברירת מחדל (או מותאם אישית).
  • מוודאים שהמנתח הפעיל שמוגדר כברירת מחדל (או המנתח המותאם אישית) של סוג היומן הרצוי קלט נתוני יומן גולמיים ב-30 הימים האחרונים. הנתונים האלה צריכים להכיל דוגמה של השדות שאתם מתכוונים לחלץ או להשתמש בהם כדי לסנן את רשומות היומן. הוא ישמש לאימות ההוראות החדשות למיפוי הנתונים.

קדימה, מתחילים

לפני שיוצרים תוסף לניתוח, צריך לבצע את הפעולות הבאות:

  1. בדיקה של הדרישות המוקדמות:

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

  2. מזהים את השדות שרוצים לחלץ מהיומנים הגולמיים:

    מזהים את השדות שרוצים לחלץ מהיומנים הגולמיים.

  3. בוחרים את השדות המתאימים ב-UDM:

    בוחרים את שדות ה-UDM המתאימים כדי למפות את השדות שחולצו מהיומן הגולמי.

  4. בחירת גישה להגדרת תוסף המנתח:

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

אימות הדרישות המוקדמות

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

מוודאים שיש מנתח פעיל לסוג היומן

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

מחפשים את סוג היומן ברשימות הבאות:

מוודאים שיש מנתח מותאם אישית לסוג היומן

כדי לוודא שיש מנתח מותאם אישית לסוג יומן:

  1. בסרגל הניווט, לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.

  2. מחפשים בטבלה Parsers את סוג היומן שרוצים להרחיב.

מוודאים שהמנתח פעיל לסוג היומן

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

  1. בסרגל הניווט, לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.

  2. מחפשים בטבלה Parsers את סוג היומן שרוצים להרחיב.

    אם המנתח של סוג היומן לא פעיל, מפעילים אותו:

מזהים את השדות שרוצים לחלץ מהיומנים הגולמיים.

מנתחים את היומן הגולמי שממנו רוצים לחלץ נתונים כדי לזהות את השדות שלא חולצו על ידי המנתח שמוגדר כברירת מחדל (או המנתח המותאם אישית). שימו לב איך המנתח שמוגדר כברירת מחדל (או המנתח המותאם אישית) מחלץ שדות של יומנים גולמיים וממפה אותם לשדות ה-UDM המתאימים.

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

לפרטים על חיפוש ביומנים הגולמיים, ראו:

בוחרים את שדות ה-UDM המתאימים

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

בחירת שדה ה-UDM הנכון

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

היכרות עם המושגים העיקריים של UDM

  • אובייקטים לוגיים: אירוע וישות

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

    • אובייקט אירוע UDM מאחסן נתונים על הפעולה שהתרחשה בסביבה. יומן האירועים המקורי מתאר את הפעולה כפי שהיא תועדה על ידי המכשיר, כמו חומת אש או שרת proxy לאינטרנט.
    • אובייקטים מסוג ישות UDM מאחסנים נתונים על המשתתפים או הישויות שמעורבים באירוע ה-UDM, כמו נכסים, משתמשים או משאבים בסביבה שלכם.

  • המבנה של אירוע UDM

  • מבנה של ישות UDM

  • שמות עצם ב-UDM: שם עצם מייצג משתתף או ישות באירוע UDM. שם עצם יכול להיות, למשל, המכשיר או המשתמש שמבצעים את הפעילות שמתוארת באירוע. שם עצם יכול להיות גם המכשיר או המשתמש שהם היעד של הפעילות שמתוארת באירוע.

    שם עצם ב-UDM תיאור
    principal הישות שאחראית על הפעולה שמתוארת באירוע.
    target הישות שהיא הנמען או האובייקט של הפעולה. בחיבור של חומת אש, המכונה שמקבלת את החיבור היא היעד.
    src ישות מקור שחשבון המשתמש ביצע בה פעולה. לדוגמה, אם משתמש מעתיק קובץ ממכונה אחת לאחרת, הקובץ והמכונה שמהם הוא הגיע יוצגו בתור src.
    intermediary כל ישות שפועלת כמתווכת באירוע, כמו שרת proxy. הם יכולים להשפיע על הפעולה, למשל לחסום או לשנות בקשה.
    observer ישות שעוקבת אחרי האירוע ומדווחת עליו, אבל לא מקיימת אינטראקציה ישירה עם התנועה. לדוגמה, מערכות לגילוי חדירות (IDS) או מערכות לניהול אבטחת מידע ואירועים (SIEM).
    about כל ישות אחרת שמעורבת באירוע ולא מתאימה לקטגוריות הקודמות. לדוגמה, קבצים מצורפים לאימייל או קובצי DLL שנטענו במהלך הפעלת תהליך.

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

הבנת מיפוי הנתונים שבו משתמש המנתח הקיים

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

כדי לראות את מיפוי הנתונים בין שדות המקור של היומן הגולמי לבין שדות היעד של ה-UDM שמשמשים במנתח ברירת המחדל הקיים (או במנתח מותאם אישית):

  1. בסרגל הניווט, לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.
  2. מחפשים בטבלה Parsers את סוג היומן שרוצים להרחיב.

  3. עוברים לשורה הזו ולוחצים על תפריט > הצגה.

    בכרטיסייה Prebuilt (או Custom), בקטע Parser Code מוצג מיפוי הנתונים בין שדות המקור של היומן הגולמי לבין שדות היעד של ה-UDM שבהם נעשה שימוש במנתח ברירת המחדל הקיים (או במנתח המותאם אישית).

שימוש בכלי UDM Lookup

אתם יכולים להשתמש בכלי החיפוש של UDM כדי לזהות שדות UDM שתואמים לשדות של מקור היומן הגולמי.

ב-Google SecOps יש את הכלי UDM Lookup, שמאפשר למצוא במהירות שדות UDM של יעדים. כדי לגשת לכלי החיפוש ב-UDM, עוברים אל Investigation‏ >‏ SIEM Search.

בנושאים הבאים מוסבר איך להשתמש בכלי החיפוש ב-UDM:

דוגמה לכלי החיפוש ב-UDM

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

  1. עוברים אל חקירה > חיפוש ב-SIEM.

  2. בדף SIEM Search, לוחצים על UDM Lookup.

    תיפתח תיבת הדו-שיח UDM Lookup. כלי החיפוש מתאים את שדות ה-UDM לפי שם השדה או ערך השדה:

    • חיפוש לפי שם שדה – התאמה של מחרוזת הטקסט שהזנתם לשמות של שדות שמכילים את הטקסט הזה.
    • חיפוש לפי ערך שדה – התאמה של הערך שהזנתם לשדות שמכילים את הערך הזה בנתוני היומן ששמורים בהם.

  3. בתיבת הדו-שיח UDM Lookup, מזינים "packets" בשדה Look up UDM fields/values ובוחרים באפשרות UDM Fields.

    פונקציית החיפוש תציג רשימה של שדות UDM פוטנציאליים שמכילים את הטקסט "packets" בשמות השדות שלהם ב-UDM.

  4. לוחצים על כל שורה בנפרד כדי לראות את התיאור של כל שדה UDM.

שיקולים חשובים לגבי UDM כדי למנוע שגיאות

  • שדות שנראים דומים: המבנה ההיררכי של UDM יכול להוביל לשדות עם שמות דומים. אפשר להיעזר במנתחי ברירת המחדל. לפרטים נוספים, ראו הסבר על מיפוי הנתונים שמשמש את המנתח הקיים.
  • מיפוי שדות שרירותי: משתמשים באובייקט additional לנתונים שלא ממופים ישירות לשדה UDM. לפרטים נוספים, ראו מיפוי שדות שרירותיים ל-UDM.
  • שדות חוזרים: צריך להיזהר כשעובדים עם שדות חוזרים בקטעי קוד. החלפה של אובייקט שלם עלולה להחליף את הנתונים המקוריים. הגישה בלי צורך בתכנות מאפשרת שליטה רבה יותר בשדות חוזרים. לפרטים נוספים, ראו בורר שדות חוזרים.
  • שדות חובה של UDM לסוגי אירועים של UDM: כשמקצים שדה UDM לרשומת UDM, כל event_type דורש קבוצה שונה של שדות קשורים שיהיו נוכחים ברשומת ה-UDM.metadata.event_type פרטים נוספים זמינים במאמר מידע נוסף על הקצאת שדות UDM של metadata.event_type.
  • בעיות במנתח הבסיסי: תוספי מנתח לא יכולים לתקן שגיאות מהמנתח הבסיסי. מנתח הנתונים הבסיסי הוא מנתח הנתונים שמוגדר כברירת מחדל (או מותאם אישית) שיצר את רשומת ה-UDM. כדאי לשקול אפשרויות כמו שיפור תוסף המנתח, שינוי המנתח הבסיסי או סינון מקדים של היומנים.
מיפוי שדות שרירותיים ל-UDM

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

בחירת גישה להגדרת תוסף מנתח

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

השלבים הבאים הם לפתוח את הדף Parser Extension ולבחור את גישת התוסף שבה רוצים להשתמש כדי להגדיר את תוסף הניתוח:

פותחים את הדף Parser Extension.

בדף Parser Extension אפשר להגדיר את תוסף המנתח החדש.

אתם יכולים לפתוח את הדף Parser Extension בדרכים הבאות, מתפריט ההגדרות, מחיפוש ביומנים גולמיים או מחיפוש ביומנים גולמיים מדור קודם:

פתיחה מתפריט ההגדרות

כדי לפתוח את הדף Parser Extension מתפריט ההגדרות:

  1. בסרגל הניווט, לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.

    בטבלה Parsers מוצגת רשימה של מנתחי ברירת מחדל לפי סוג היומן.

  2. מוצאים את סוג היומן שרוצים להרחיב, לוחצים על Menu > Extend Parser > Create Extension.

    הדף Parser Extension נפתח.

כדי לפתוח את הדף Parser Extension מתוך Raw Log Search:

  1. עוברים אל חקירה > חיפוש ב-SIEM.
  2. בשדה החיפוש, מוסיפים את הקידומת raw = לארגומנט החיפוש ומקיפים את מונח החיפוש במירכאות. לדוגמה, raw = "example.com".
  3. לוחצים על הפעלת החיפוש. התוצאות מוצגות בחלונית Raw Logs.
  4. לוחצים על יומן (שורה) בחלונית Raw Logs. החלונית Event Viewer מוצגת.
  5. לוחצים על הכרטיסייה Raw Log בחלונית Event Viewer. היומן הגולמי מוצג.

  6. לוחצים על Manage Parser > Extend Parser > Create Extension (או בוחרים באפשרות Create Extension > Next).

    הדף Parser Extension נפתח.

כדי לפתוח את הדף Parser Extension מחיפוש ביומנים גולמיים מהגרסה הקודמת:

  1. משתמשים ב-Raw Log Search הקודם כדי לחפש רשומות שדומות לאלה שינותחו.
  2. בוחרים אירוע (או לוחצים על סמל היומן הגולמי) בחלונית ציר הזמן כדי לפתוח את היומן הגולמי.

  3. לוחצים על Manage Parser > Extend Parser > Create Extension (או בוחרים באפשרות Create Extension > Next).

    הדף Parser Extension נפתח.

דף התוסף Parser

בדף מוצגות החלוניות Raw Log ו-Extension (הגדרת התוסף):

  • החלונית Raw Log:

    כך מוצגים נתונים לדוגמה של יומן גולמי לסוג היומן שנבחר. אם פתחתם את הדף מחיפוש ביומן הגולמי, הנתונים לדוגמה הם תוצאת החיפוש. אפשר לעצב את הדגימה באמצעות התפריט View as (Raw,‏ JSON,‏ CSV,‏ XML או Hex/ASCII) ותיבת הסימון Wrap Text.

    1. מוודאים שהדוגמה של נתוני היומן הגולמיים שמוצגת מייצגת את היומנים שתוסף הניתוח יעבד.

    2. לוחצים על Preview UDM Output (או על Show UDM Output) כדי לראות את פלט ה-UDM של נתוני היומן הגולמיים לדוגמה.

  • חלונית תוסף (הגדרת תוסף):

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

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

בחירת גישת ההרחבה

בדף Parser Extension, בחלונית Extension, בשדה Extension Method, בוחרים באחת מהשיטות הבאות ליצירת תוסף המנתח:

  • מיפוי שדות נתונים (בלי צורך בתכנות):

    בגישה הזו אתם יכולים לציין את השדות ביומן הגולמי ולמפות אותם לשדות UDM ביעד.

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

    • ‫JSON מקורי, XML מקורי או CSV.
    • כותרת Syslog וגם JSON מקורי, XML מקורי או CSV. אפשר ליצור הוראות מיפוי של סוגי שדות נתונים ליומנים גולמיים בפורמטים הבאים: JSON,‏ XML,‏ CSV,‏ SYSLOG + JSON,‏ SYSLOG + XML ו-SYSLOG + CSV.

    השלבים הבאים: יצירת הוראות בלי צורך בתכנות (מיפוי שדות נתונים)

  • גישת כתיבת קטעי קוד (או כתיבת קטע קוד):

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

    • קטעי קוד משתמשים באותו תחביר ובאותם קטעים כמו מנתחים שמוגדרים כברירת מחדל (או מותאמים אישית). מידע נוסף זמין במאמר תחביר מנתח.

    • הגישה הזו פועלת עם כל פורמטי הנתונים הנתמכים של סוג היומן הזה.

    הוראות ליצירת קטע קוד.

הוראות ליצירת הוראות בלי צורך בקוד (מיפוי שדות נתונים)

הגישה בלי צורך בתכנות (שנקראת גם השיטה מיפוי שדות נתונים) מאפשרת לציין את הנתיבים של שדות היומן הגולמיים ולמפות אותם לשדות UDM תואמים ביעד.

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

השלבים הבאים להגדרת תוסף המנתח הם:

  1. הגדרת בורר השדות החוזרים
  2. הגדרת הוראה למיפוי נתונים לכל שדה
  3. שליחה והפעלה של תוסף המנתח

הגדרת הוראה למיפוי נתונים לכל שדה

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

  1. אם דגימת היומן הגולמי שמוצגת בחלונית Raw Log מכילה כותרת Syslog, השדות Syslog ו-Target מוצגים. (חלק מהפורמטים של היומנים לא מכילים כותרת Syslog, למשל, JSON מקורי, XML מקורי או CSV).

    כדי לעבד מראש את הכותרת של Syslog ולחלץ את החלק המובנה של היומן, Google SecOps צריך את השדות Syslog ו-Target.

    1. מגדירים את השדות הבאים:

      • ‫Syslog: תבנית שמוגדרת על ידי המשתמש, שמעבדת מראש ומפרידה את כותרת ה-Syslog מהחלק המובנה של היומן הגולמי.

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

      • ‫Target: שם המשתנה בשדה Syslog שבו מאוחסן החלק המובנה של היומן.

        מציינים את שם המשתנה בתבנית החילוץ שבה מאוחסן החלק המובנה של היומן.

      זו דוגמה לתבנית חילוץ ולשם משתנה בשדות Syslog ו-Target, בהתאמה.

      שדות לחילוץ מ-Syslog

    2. אחרי שמזינים ערכים בשדות Syslog ו-Target, לוחצים על הלחצן Validate.

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

      • הצלחה: שדות מיפוי הנתונים מופיעים. מגדירים את שאר התוסף לניתוח.
      • נכשל: מופיעה הודעת שגיאה. צריך לתקן את השגיאה לפני שממשיכים.

  2. אפשר גם להגדיר הוראה לתנאי מקדים.

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

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

    • ‫Precondition Field (או Precondition Column בקובץ CSV): מזהה השדה ביומן הגולמי שמכיל את הערך להשוואה. מזינים את הנתיב המלא לשדה אם פורמט הנתונים של היומן הוא JSON או XML, או את מיקום העמודה אם פורמט הנתונים הוא CSV.
    • אופרטור של תנאי מקדים: בוחרים באפשרות שווה ל- או לא שווה ל-.
    • Precondition Value: הערך הסטטי שיושווה ל-Precondition Field ביומן הגולמי.

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

  3. ממפים את שדה הנתונים של היומן הגולמי לשדה היעד ב-UDM:

    • שדה נתונים גולמיים (או עמודת נתונים גולמיים ב-CSV): מזינים את הנתיב המלא לשדה אם פורמט נתוני היומן הוא JSON (לדוגמה: jsonPayload.connection.dest_ip) או XML (לדוגמה: /Event/Reason-Code), או את מיקום העמודה אם פורמט הנתונים הוא CSV (הערה: מיקומי האינדקס מתחילים ב-1).

    • שדה יעד: מזינים את השם המלא של שדה ה-UDM שבו הערך יישמר, לדוגמה udm.metadata.collected_timestamp.seconds.

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

דוגמה נוספת למיפוי השדות מופיעה במאמר בלי צורך בתכנות – חילוץ שדות.

שליחה והפעלה של תוסף המנתח

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

לוחצים על Submit כדי לשמור ולאמת את הוראת המיפוי.

מערכת Google SecOps מאמתת את הוראות המיפוי:

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

  • אם תהליך האימות נכשל, המצב משתנה לנכשל ותופיע שגיאה בשדה "יומן גולמי".

    דוגמה לשגיאת אימות:

      ERROR: generic::unknown: pipeline.ParseLogEntry failed: LOG_PARSING_CBN_ERROR:
  "generic::invalid_argument: pipeline failed: filter mutate (7) failed: copy failure:
  copy source field \"jsonPayload.dest_instance.region\" must not be empty
  (try using replace to provide the value before calling copy)

  "LOG: {"insertId":"14suym9fw9f63r","jsonPayload":{"bytes_sent":"492",
  "connection":{"dest_ip":"10.12.12.33","dest_port":32768,"protocol":6,
  "src_ip":"10.142.0.238","src_port":22},"end_time":"2023-02-13T22:38:30.490546349Z",
  "packets_sent":"15","reporter":"SRC","src_instance":{"project_id":"example-labs",
  "region":"us-east1","vm_name":"example-us-east1","zone":"us-east1-b"},
  "src_vpc":{"project_id":"example-labs","subnetwork_name":"default",
  "vpc_name":"default"},"start_time":"2023-02-13T22:38:29.024032655Z"},
  "logName":"projects/example-labs/logs/compute.googleapis.com%2Fvpc_flows",
  "receiveTimestamp":"2023-02-13T22:38:37.443315735Z","resource":{"labels":
  {"location":"us-east1-b","project_id":"example-labs",
    "subnetwork_id":"00000000000000000000","subnetwork_name":"default"},
    "type":"gce_subnetwork"},"timestamp":"2023-02-13T22:38:37.443315735Z"}

    מצבים במחזור החיים של תוסף מנתח

    לתוספי מנתח יש את מצבי מחזור החיים הבאים:

  • ‫DRAFT: תוסף מנתח שנוצר לאחרונה ועדיין לא נשלח.

  • ‫VALIDATING: מערכת Google SecOps מאמתת את הוראות המיפוי מול יומנים גולמיים קיימים כדי לוודא שהשדות מנותחים ללא שגיאות.

  • ‫LIVE: תוסף המנתח עבר את האימות ועכשיו הוא בסביבת הייצור. הוא מחלץ נתונים מיומנים גולמיים נכנסים וממיר אותם לרשומות UDM.

  • ‫FAILED: האימות של תוסף המנתח נכשל.

מידע נוסף על השדות של חילוץ Syslog

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

הגדרת השדות של חילוץ Syslog

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

הדוגמה הבאה ממחישה איך השדות האלה פועלים יחד.

דוגמה ליומן גולמי:

<13>1 2022-09-14T15:03:04+00:00 fieldname fieldname - - - {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

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

  • כותרת Syslog:‏ <13> 2022-09-14T15:03:04+00:00 fieldname fieldname - - -

  • אירוע בפורמט JSON: ‏{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

כדי להפריד בין הכותרת של Syslog לבין החלק של ה-JSON ביומן הגולמי, משתמשים בביטוי לדוגמה הבא בשדה Syslog: %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

  • החלק הזה של הביטוי מזהה את הכותרת של Syslog: %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
  • החלק הזה של הביטוי מתעד את קטע ה-JSON של היומן הגולמי: %{GREEDYDATA:msg}

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

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

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

{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

ככה נראים השדות Syslog ו-Target אחרי שממלאים אותם:

שדות לחילוץ מ-Syslog

בטבלה הבאה מופיעות דוגמאות נוספות עם יומנים לדוגמה, תבנית החילוץ של Syslog, שם המשתנה Target והתוצאה.

יומן גולמי לדוגמה שדה Syslog שדה היעד תוצאה
<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg} msg field_mappings { field: "msg" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }
<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"} %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg1} ([- ]+)?%{GREEDYDATA:msg2} msg2 field_mappings { field: "msg2" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }
"<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:message} ([- ]+)?%{GREEDYDATA:msg2} msg2 Error - message already exists in state and not overwritable.

מידע נוסף על הקצאת שדות metadata.event_type ב-UDM

כשמקצים שדה UDM metadata.event_type לרשומת UDM, המערכת מאמתת אותו כדי לוודא שהשדות הקשורים הנדרשים קיימים ברשומת ה-UDM. לכל metadata.event_type של UDM נדרשת קבוצה שונה של שדות קשורים. לדוגמה, אירוע USER_LOGIN בלי user לא שימושי.

אם חסר שדה קשור שנדרש, האימות של ה-UDM מחזיר שגיאה:

  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT"
  }

מנתח Grok מחזיר שגיאה מפורטת יותר:

  generic::unknown:
  invalid event 0: LOG_PARSING_GENERATED_INVALID_EVENT:
  "generic::invalid_argument: udm validation failed: target field is not set"

כדי למצוא את השדות הנדרשים להקצאה של event_type ב-UDM, אתם יכולים להשתמש במקורות המידע הבאים. המדריכים להטמעה משלימים את המדריך לשימוש ב-UDM, ומספקים את השדות המינימליים הנדרשים ב-UDM כדי לאכלס metadata.event_type נתון ב-UDM.

לדוגמה, פותחים את המסמך ומחפשים את סוג האירוע GROUP_CREATION.

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

  {
      "metadata": {
          "event_timestamp": "2023-07-03T13:01:10.957803Z",
          "event_type": "GROUP_CREATION"
      },
      "principal": {
          "user": {
              "userid": "pinguino"
          }
      },
      "target": {
          "group": {
              "group_display_name": "foobar_users"
          }
      }
  }

הוראות ליצירת קטע קוד

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

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

השלבים הבאים להגדרת תוסף המנתח הם:

  1. טיפים ושיטות מומלצות לכתיבת הוראות לקטעי קוד
  2. יצירת הוראה לקטע קוד
  3. שליחת הוראה להוספת קטע קוד

טיפים ושיטות מומלצות לכתיבת הוראות לקטעי קוד

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

יצירת הוראה לקטע קוד

ההוראות של קטע הקוד משתמשות באותו תחביר ובאותם קטעים כמו המנתח שמוגדר כברירת מחדל (או המנתח בהתאמה אישית):

  • חלק 1. מחלצים נתונים מהיומן הגולמי.
  • חלק 2. משנים את הנתונים שחולצו.
  • חלק 3. מקצים ערך אחד או יותר לשדה UDM.
  • סעיף 4. מקשרים שדות של אירועי UDM למפתח @output.

כדי ליצור תוסף לניתוח באמצעות גישת קטע הקוד:

  1. בדף Parser Extension, בחלונית CBN Snippet, מזינים קטע קוד כדי ליצור את תוסף המנתח.
  2. לוחצים על אימות כדי לאמת את הוראות המיפוי.

דוגמאות להוראות של קטעי קוד

הדוגמה הבאה ממחישה קטע קוד.

זו דוגמה ליומן הגולמי (עם שדות jsonPayload נוספים שהושמטו כדי לקצר):

  {
      "insertId": "00000000",
      "jsonPayload": {
          "packets_sent": "4"
      },
      "timestamp": "2022-05-03T01:45:00.150614953Z"
  }

דוגמה לקטע קוד שממפה את הערך ב-jsonPayload.packets_sent לשדה network.sent_bytes ב-UDM:

filter {
  mutate {
    replace => {
      "jsonPayload.packets_sent" => ""
    }
  }
  # Section 1. extract data from the raw JSON log
  json {
    source => "message"
    array_function => "split_columns"
    on_error => "_not_json"
  }
  if [_not_json] {
    drop {
      tag => "TAG_UNSUPPORTED"
    }
  } else {
    # Section 2. transform the extracted data
    if [jsonPayload][packets_sent] not in ["", 0] {
      mutate {
        convert => {
          "jsonPayload.packets_sent" => "uinteger"
        }
        on_error => "_exception1"
      }
      # Section 3. assign the value to a UDM field
      mutate {
        Replace => {
          "event.idm.read_only_udm.network.sent_bytes" => "jsonPayload.packets_sent"
        }
        on_error => "_exception2"
      }
      if ![_exception1] and![_exception2] {
        # Section 4. Bind the UDM fields to the @output key
        mutate {
          merge => {
            "@output" => "event"
          }
        }
      }
    }
  }
}

שליחת הוראה לקטע קוד

  1. לוחצים על שליחה כדי לשמור את הוראות המיפוי.

  2. מערכת Google SecOps מאמתת את הוראות המיפוי.

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

ניהול תוספי מנתח קיימים

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

הצגת תוסף קיים לניתוח (parser)

  1. בסרגל הניווט, לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.
  2. ברשימת המנתחים, מוצאים את המנתח (סוג היומן) שרוצים לראות. מנתחי נתונים עם תוסף מסומנים בטקסט EXTENSION (או EXTN) ליד השם שלהם.

  3. עוברים לשורה הזו ולוחצים על Menu ‏> Extend Parser ‏> View Extension.

    הכרטיסייה View Custom/Prebuilt Parser > Extension (או הכרטיסייה Extensions) מופיעה עם פרטים על תוסף המנתח. כברירת מחדל, בחלונית הסיכום מוצג תוסף המנתח (parser) LIVE.

עריכת תוסף לניתוח (parsing)

  1. פותחים את הכרטיסייה View Custom/Prebuilt Parser > Extension (או הכרטיסייה Extensions), כמו שמתואר בקטע הצגת תוסף קיים של מנתח.

  2. לוחצים על הכפתור עריכת התוסף (או עריכה).

    מופיע הדף Parser Extension.

  3. עורכים את תוסף המנתח.

    • כדי לבטל את העריכה ולמחוק את השינויים, לוחצים על מחיקת הטיוטה (או מחיקת התוסף).

    • כדי למחוק את תוסף הניתוח, לוחצים על Delete Failed Extension (או על Delete Extension).

    • כשמסיימים לערוך את תוסף הניתוח, לוחצים על Submit.

      תהליך האימות פועל כדי לאמת את ההגדרה החדשה.

מחיקה של תוסף לניתוח טקסט (parser)

  1. פותחים את הכרטיסייה View Custom/Prebuilt Parser > Extension (או הכרטיסייה Extensions), כמו שמתואר בקטע הצגת תוסף קיים של מנתח.

  2. לוחצים על הכפתור מחיקת התוסף.

שליטה בגישה לתוספי מנתח (parser)

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

התפקידים החדשים ב-Google SecOps מפורטים בטבלה הבאה.

התכונה פעולה תיאור
מנתח מחיקה מחיקת תוספי מנתח.
מנתח עריכה יצירה ועריכה של תוספי מנתח.
מנתח הצגה הצגת תוספי מנתח.

הסרת מיפויים של שדות UDM באמצעות תוספי מנתח נתונים

אתם יכולים להשתמש בתוספים למנתח כדי להסיר מיפוי קיים של שדה UDM.

  1. לוחצים על הגדרות > ניהול נתונים > מנתחי נתונים. אם אתם משתמשים בפלטפורמה של SIEM בלבד, עוברים אל הגדרות > מנתחי נתונים.
  2. כדי להציג את הדף Parser Extension, משתמשים באחת מהשיטות הבאות:
    • אם רוצים להרחיב מנתח קיים, לוחצים על Menu ‏> Extend Parser ‏> ‏View Extension.
    • כדי ליצור תוסף חדש למנתח, לוחצים על תפריט > הרחבת המנתח > יצירת תוסף.

  3. כדי להוסיף קטע קוד בהתאמה אישית שמסיר ערכים של שדות UDM ספציפיים, בוחרים באפשרות Write Code Snippets (או Write code snippet) בתור שיטת התוסף.

    אם התוסף כבר קיים, בכרטיסייה Extension (תוסף) (או Extensions (תוספים)), לוחצים על Edit Extension (עריכת התוסף) (או Edit (עריכה)) ואז מוסיפים את קטע הקוד.

    דוגמאות לקטעי קוד מופיעות בקטע קטע קוד – הסרת מיפויים קיימים.

  4. פועלים לפי השלבים בקטע שליחת הוראה של קטע קוד כדי לשלוח את התוסף.

טיפול באזורי זמן ועיצוב חותמות זמן

מערכת Google SecOps מתקננת ומסדרת חותמות זמן בפורמט RFC 3339 UTC, עם דיוק של מיקרו-שניות (YYYY-MM-DDTHH:MM:SS.ffffffZ). אם יומני המקור מספקים דיוק של שניות בלבד, הפלטפורמה מוסיפה באופן אוטומטי אפסים בסוף (.000000Z) כדי לשמור על אחידות הסכימה.

אם חותמת הזמן של אירוע מופיעה לפני זמן ההטמעה (ingested_timestamp < event_timestamp), בדרך כלל הפער נוצר כשמקור פולט חותמות זמן מקומיות של שעון קיר ללא היסטים של אזור זמן לפי תקן ISO (שמוגדרים כברירת מחדל ל-UTC) או כשיש סטייה בשעון. כדי לפתור את הבעיה, אתם יכולים להשתמש באחת מהשיטות הבאות:

  • התאמת חותמות זמן בתוסף לניתוח: משתמשים במסנן date בתוסף לניתוח של קטע קוד כדי לציין את אזור הזמן של המקור:

    if [raw_log] =~ /EST/ {
  date {
    match => [ "timestamp_str", "MMM dd HH:mm:ss" ]
    timezone => "America/New_York"
    target => "event.metadata.event_timestamp"
  }
}

  • הגדרת שינוי של אזור הזמן של אוסף הנתונים של ה-forwarder: עוברים אל הגדרות > ניהול נתונים > Forwarders, עורכים את אוסף הנתונים של היעד, מפעילים את האפשרות שינוי אזור הזמן ובוחרים את אזור הזמן של המקור ב-IANA בתפריט אזור זמן (לדוגמה, Europe/Paris) כדי לשנות את חותמות הזמן באופן אוטומטי במהלך ההטמעה.

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