איסוף יומנים של Cisco Identity Intelligence

נתמך ב:

Google SecOps SIEM

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

במאמר הזה מוסבר איך להגדיר את Cisco Identity Intelligence כדי לשלוח יומנים ל-Google Security Operations באמצעות תגובות לפעילות אינטרנט.

‫Cisco Identity Intelligence (לשעבר Oort Security) היא פלטפורמה לזיהוי איומים על זהות ולתגובה להם, שעוקבת באופן רציף אחרי התנהגות המשתמשים, דפוסי האימות, השימוש במכשירים והרשאות הגישה אצל ספקי הזהויות. הוא מנתח את פעילות המשתמשים, בדיקות אבטחה שנכשלו, ציוני מהימנות והתנהגויות מסוכנות כדי לזהות איומים מבוססי-זהות, הגדרות שגויות והפרות של תאימות.

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

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

• מכונה של Google SecOps
• גישה מורחבת לדייר (tenant) ב-Cisco Identity Intelligence
• הרשאות אדמין לניהול שילובים ב-Cisco Identity Intelligence
• גישה למסוף Google Cloud (כדי ליצור מפתח API)

יצירת פיד של webhook ב-Google SecOps

יצירת הפיד

1. עוברים אל SIEM Settings > Feeds.
2. לוחצים על הוספת פיד חדש.
3. בדף הבא, לוחצים על הגדרת פיד יחיד.
4. בשדה שם הפיד, מזינים שם לפיד (לדוגמה, Cisco Identity Intelligence Events).
5. בוחרים באפשרות Webhook בתור סוג המקור.
6. בוחרים באפשרות Cisco Identity Intelligence בתור סוג היומן.
7. לוחצים על הבא.
8. מציינים ערכים לפרמטרים הבאים של הקלט:
   • תו מפריד לפיצול (אופציונלי): מזינים \n כדי לפצל אירועים מרובי שורות.
   • מרחב השמות של הנכס: מרחב השמות של הנכס
   • תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה
9. לוחצים על הבא.
10. בודקים את הגדרות הפיד החדש במסך סיום ולוחצים על שליחה.

יצירה ושמירה של מפתח סודי

אחרי שיוצרים את הפיד, צריך ליצור מפתח סודי לאימות:

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

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

קבלת כתובת ה-URL של נקודת הקצה של הפיד

1. עוברים לכרטיסייה פרטים של הפיד.
2. בקטע Endpoint Information, מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד.

3. הפורמט של כתובת ה-URL הוא:

   https://{region}-chronicle.googleapis.com/v1/{parent}/logs:import
   

   כאשר {region} הוא האזור של מופע Google SecOps (לדוגמה, us,‏ europe או asia-southeast1), ו-{parent} הוא נתיב המשאב בפורמט projects/<PROJECT_ID>/locations/<LOCATION>/instances/<INSTANCE_ID>/logTypes/<LOG_TYPE>.

4. שומרים את כתובת ה-URL הזו לשלבים הבאים.

5. לוחצים על סיום.

יצירת מפתח API של Google Cloud

כדי לבצע אימות ב-Chronicle, צריך מפתח API. יוצרים מפתח API מוגבל במסוף Google Cloud.

יצירת מפתח API

1. נכנסים אל הדף Credentials במסוף Google Cloud.
2. בוחרים את הפרויקט (הפרויקט שמשויך למכונה של Chronicle).
3. לוחצים על Create credentials > מפתח API.
4. מפתח API נוצר ומוצג בתיבת דו-שיח.
5. לוחצים על Edit API key כדי להגביל את המפתח.

הגבלת מפתח ה-API

1. בדף ההגדרות מפתח API:
   • שם: מזינים שם תיאורי (לדוגמה, Chronicle Webhook API Key)
2. בקטע API restrictions (הגבלות על API):
   1. בוחרים באפשרות Restrict key.
   2. בתפריט הנפתח Select APIs (בחירת ממשקי API), מחפשים את Google SecOps API (או Chronicle API) ובוחרים אותו.
3. לוחצים על Save.
4. מעתיקים את הערך של מפתח ה-API מהשדה API key שבחלק העליון של הדף.
5. שומרים את מפתח ה-API בצורה מאובטחת.

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

הגדרת ה-webhook של Cisco Identity Intelligence

יצירת כתובת ה-URL של ה-webhook

• משלבים את כתובת ה-URL של נקודת הקצה ב-Chronicle ואת מפתח ה-API:

  <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>
  

  • לדוגמה:

    https://{region}-chronicle.googleapis.com/v1/{parent}/logs:import?key=AIzaSyD...&secret=abcd1234...
    

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

• ‫<ENDPOINT_URL>: כתובת ה-URL של נקודת הקצה של הפיד ב-Chronicle שהעתקתם קודם
• ‫<API_KEY>: מפתח Google Cloud API שנוצר קודם
• ‫<SECRET_KEY>: המפתח הסודי של ה-webhook ב-Chronicle שנוצר קודם לכן

יצירת יעד התראה של תגובה לפעולה מאתר אחר (webhook) ב-Cisco Identity Intelligence

1. נכנסים אל Cisco Identity Intelligence.
2. עוברים אל שילובים.
3. לוחצים על Add Integration (הוספת שילוב).
4. גוללים למטה לקטע Webhook.
5. לוחצים על Add Webhook Target.
6. מספקים את פרטי ההגדרה הבאים:
   • שם: מזינים שם תיאורי (לדוגמה, Chronicle SIEM Integration).
   • Webhook URL: מדביקים את כתובת ה-URL המלאה של נקודת הקצה עם מפתח ה-API והמפתח הסודי שצוינו למעלה.
   • Authorization Type (סוג ההרשאה): בוחרים באפשרות API Key (מפתח API).
   • שם מפתח ה-API: מזינים שם למפתח (לדוגמה, x-goog-chronicle-auth).
   • ‫API Key Value: מזינים את מפתח ה-API של Google Cloud.
7. מרחיבים את הקטע Invocation HTTP Parameters.
8. מוסיפים את הפרמטרים הבאים עם הסוג Header:
   • מפתח: Content-Type, ערך: application/json
   • מפתח: Accept, ערך: application/json
9. בקטע Use this target for, בוחרים באפשרות Failed Check כדי לקבל התראות כשבדיקות הזהות נכשלות.

10. לוחצים על Save.

    הערה: ליעד של ה-webhook צריך להיות אישור ציבורי מהימן ותקף. אין תמיכה באישורים מ-PKI פרטי.

בדיקת החיבור של ה-webhook

1. בדף Integrations (שילובים), מוצאים את יעד ההתראה של ה-webhook שיצרתם.
2. לוחצים על סמל האפשרויות הנוספות (3 נקודות) בצד שמאל של השורה.
3. לוחצים על בדיקת הקישוריות.
4. מוודאים שהודעת הבדיקה נמסרה בהצלחה.

הפעלת ה-webhook לבדיקות זהות

אחרי שיוצרים את יעד ההתראה של ה-webhook, צריך להפעיל אותו עבור בדיקות הזהות הספציפיות שרוצים לעקוב אחריהן.

1. עוברים לדף הפרטים של הבדיקה הרצויה ב-Cisco Identity Intelligence.
2. מרחיבים את התפריט הנפתח בפינה השמאלית העליונה של הדף.
3. מסמנים את התיבה של יעד ההתראות של ה-webhook שיצרתם.

4. חוזרים על הפעולה הזו לכל בדיקה שרוצים לשלוח ל-Google SecOps.

   הערה: לא יישלח דבר דרך ה-webhook עד שהוא יופעל לפחות לבדיקת זהות אחת. אחרי שמפעילים את Cisco Identity Intelligence, המערכת שולחת אירוע ל-webhook פעם ביום עם מטען ייעודי (payload) שכולל את רשימת המשתמשים החדשים שנכשלו בבדיקה שהופעלה.

מידע נוסף זמין במסמכי התיעוד של Cisco Identity Intelligence בנושא webhook.

מידע על שיטות אימות

פידים של Chronicle webhook תומכים בכמה שיטות אימות. בוחרים את השיטה שבה הספק תומך.

שיטה 1: כותרות בהתאמה אישית (מומלץ)

אם הספק תומך בכותרות HTTP בהתאמה אישית, כדאי להשתמש בשיטה הזו כדי לשפר את האבטחה.

• פורמט הבקשה:

  POST <ENDPOINT_URL> HTTP/1.1
  Content-Type: application/json
  x-goog-chronicle-auth: <API_KEY>
  x-chronicle-auth: <SECRET_KEY>
  
  {
      "event": "data",
      "timestamp": "2025-01-15T10:30:00Z"
  }
  

היתרונות:

• מפתח ה-API והסוד לא גלויים בכתובת ה-URL
• מאובטח יותר (הכותרות לא מתועדות ביומני הגישה של שרת האינטרנט)
• השיטה המועדפת אם הספק תומך בה

שיטה 2: פרמטרים של שאילתה

אם הספק לא תומך בכותרות מותאמות אישית, צריך לצרף את פרטי הכניסה לכתובת ה-URL.

• פורמט כתובת ה-URL:

  <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>
  

• לדוגמה:

  https://{region}-chronicle.googleapis.com/v1/{parent}/logs:import?key=AIzaSyD...&secret=abcd1234...
  

• פורמט הבקשה:

  POST <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY> HTTP/1.1
  Content-Type: application/json
  
  {
      "event": "data",
      "timestamp": "2025-01-15T10:30:00Z"
  }
  

החסרונות:

• פרטי כניסה שגלויים בכתובת ה-URL
• יכול להיות שהם יתועדו ביומני הגישה של שרת האינטרנט
• פחות מאובטח מכותרות

שיטה 3: היברידית (כתובת URL + כותרת)

בחלק מההגדרות, מפתח ה-API נמצא בכתובת ה-URL והמפתח הסודי נמצא בכותרת.

• פורמט הבקשה:

  POST <ENDPOINT_URL>?key=<API_KEY> HTTP/1.1
  Content-Type: application/json
  x-chronicle-auth: <SECRET_KEY>
  
  {
      "event": "data",
      "timestamp": "2025-01-15T10:30:00Z"
  }
  

שמות של כותרות אימות

מערכת Chronicle מקבלת את שמות הכותרות הבאים לאימות:

למפתח API:

• x-goog-chronicle-auth (מומלץ)
• X-Goog-Chronicle-Auth (לא תלוי-רישיות)

למפתח סודי:

• x-chronicle-auth (מומלץ)
• X-Chronicle-Auth (לא תלוי-רישיות)

הערה: Cisco Identity Intelligence תומך בכותרות HTTP מותאמות אישית באמצעות פרמטרים של הפעלת HTTP. אפשר להשתמש בשיטת הפרמטרים של השאילתה (שיטה 2) על ידי הוספת פרטי כניסה ל-webhook URL, או להגדיר כותרות בהתאמה אישית (שיטה 1) דרך הקטע "פרמטרים של HTTP להפעלה". שיטת הפרמטרים של השאילתה היא הגישה הפשוטה ביותר לשילוב הזה.

מגבלות ושיטות מומלצות לשימוש ב-webhook

מגבלות על בקשות

הגבלה	ערך
גודל בקשה מקסימלי	‫4MB
מספר מקסימלי של שאילתות לשנייה (QPS)	15,000
פסק זמן של בקשה	‫30 שניות
התנהגות של ניסיון חוזר	אוטומטי עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

טבלת מיפוי UDM

שדה ביומן	מיפוי UDM	היגיון
חשבון	account_label.value	הערך הועתק ישירות
חשבון	account_label.key	צריך להגדיר את הערך "account"
account_label	security_result.detection_fields	מוזג ל-detection_fields
additional_detaildescription.key	additional_detaildescription.key	הוגדר כ'תיאור מפורט'
detaildescription	additional_detaildescription.value.list_value.values	מוזג מ-detaildescription
additional_detaildescription	event.idm.read_only_udm.additional.fields	מוזג לתוך additional.fields
additional_recommendedaction.key	additional_recommendedaction.key	מוגדר כ'פעולה מומלצת'
recommendedAction	additional_recommendedaction.value.list_value.values	Merged from recommendedAction
additional_recommendedaction	event.idm.read_only_udm.additional.fields	מוזג לתוך additional.fields
data1	usersFailing_label	הערך הועתק ישירות
data.login	login_label	הערך הועתק ישירות
detail-type	security_result.summary	הערך הועתק ישירות
detail.id	security_result.rule_id	הערך הועתק ישירות
detail.title	security_result.rule_name	הערך הועתק ישירות
detail.severity	security_result.severity	הערך מ-detail.severity אם הוא נמצא ב-[CRITICAL,ERROR,HIGH,INFORMATIONAL,LOW,MEDIUM], אחרת הערך הוא MEDIUM אם הוא מתון
detaildescription	value_array.string_value	הערך הועתק ישירות
detailsdata.key	add_label.value, add_label.key	הערך מ-detailsdata.value, המפתח הוא loginDetails %{index} details %{detailindex} %{detailsdata.key} אם לא מדובר ב-failedSigninDetails או ב-ips
detailsdata.value	add_label.value, add_label.key
detailsdata.key	security_result.detection_fields	התג add_label מוזג אם התנאים התקיימו
detailsdata.value	security_result.detection_fields
field_.value	security_result.detection_fields	מוזגו לשדות שונים בתצוגת עץ ב-json_array‏ (msg,‏ ipInfo,‏ asn,‏ coordinates,‏ first_event,‏ second_event,‏ locations) עם מפתחות כמו "‎%{index} %{detailindex} %{index1} %{key}‎" וכו', לא כולל ipAddress,‏ ip וכו'.
field_.key	security_result.detection_fields
id	metadata.product_log_id	הערך הועתק ישירות
login_label	principal.user.email_addresses	מיזוג אם יש התאמה לביטוי הרגולרי של כתובת אימייל
msg.ipAddress	principal.ip	מיזוג אם לא ריק
msg.first_event.ip_address	principal.ip	אם הוא לא ריק, הוא ימוזג
msg.second_event.ip_address	principal.ip	אם הוא לא ריק, הוא ימוזג
msg_travels_first_event_ip_address	principal.ip	מיזוג אם לא ריק
msg_travels_second_event_ip_address	principal.ip
recommendedAction	value_array.string_value	הערך הועתק ישירות
security_result	event.idm.read_only_udm.security_result	מוזג ל-security_result
מקור	source_label.value	הערך הועתק ישירות
מקור	source_label.key	הגדרה ל "מקור"
source_label	event.idm.read_only_udm.src.labels	מוזגה ל-src.labels
פעם	@timestamp	הניתוח מתבצע באמצעות מסנן תאריכים עם ISO8601, ‏ RFC 3339, ‏ yyyy-MM-ddTHH:mm:ss.SSSSSSZ
usersFailing_label	principal.user.email_addresses	מיזוג אם יש התאמה לביטוי הרגולרי של כתובת אימייל
גרסה	metadata.product_version	הערך הועתק ישירות
has_principal	event.idm.read_only_udm.metadata.event_type	הערך שמוגדר הוא STATUS_UPDATE אם has_principal הוא true, אחרת USER_UNCATEGORIZED אם has_user הוא true, אחרת GENERIC_EVENT
has_user	event.idm.read_only_udm.metadata.event_type
metadata.product_name	metadata.product_name	הגדרה ל-"OORT"
metadata.vendor_name	metadata.vendor_name	ההגדרה היא OORT
detail.published	event.idm.read_only_udm.metadata.collected_timestamp	מופה מיומן השינויים
detail.login	event.idm.read_only_udm.principal.user.userid	מופה מיומן השינויים
detail.userTrustLevel	event.idm.read_only_udm.principal.user.attribute.labels	מופה מיומן השינויים
detail.login	event.idm.read_only_udm.principal.user.user_display_name	מופה מיומן השינויים
detail.checkTopics	event.idm.read_only_udm.security_result.category_details	מופה מיומן השינויים
region	event.idm.read_only_udm.additional.fields	מופה מיומן השינויים
detail.checkId	event.idm.read_only_udm.security_result.detection_fields	מופה מיומן השינויים
detail.checkScope	event.idm.read_only_udm.security_result.detection_fields	מופה מיומן השינויים
detail.frameworks	event.idm.read_only_udm.security_result.detection_fields	מופה מיומן השינויים
detail.explainabilityEventIds	event.idm.read_only_udm.security_result.detection_fields	מופה מיומן השינויים
data.value	event.idm.read_only_udm.security_result.detection_fields	מופה מיומן השינויים

יומן שינויים

צפייה ביומן השינויים של המנתח הזה

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