שילוב של פידים משלכם של מודיעין איומי סייבר

נתמך ב:

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

שילוב של פידים מותאמים אישית של מודיעין איומי סייבר מאפשר לצוות תפעול אבטחה (SecOps) שלכם לשלב זרמים של אינדיקטורים חיצוניים (כמו Malware Information Sharing Platform‏ (MISP),‏ STIX/TAXII או פידים מסחריים) עם טלמטריית האבטחה הפנימית שלכם. אחרי הנורמליזציה ל-ECG, ישויות האיום תומכות בהתאמה אוטומטית של אינדיקטורים וגם בכללי קורלציה מותאמים אישית של YARA-L 2.0 למספר אירועים.

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

  • גרף הקשר של ישויות (ECG): שכבת האחסון ההקשרית ב-Google SecOps ששומרת רשומות של ישויות עם מצב (כמו נכסים, משתמשים ואינדיקטורים של איומים) לצורך קורלציה עם יומני אירועי אבטחה.
  • מודל נתונים מאוחד (UDM): סכימה סטנדרטית ש-Google SecOps משתמשת בה כדי לנרמל יומני אירועים גולמיים ונתוני ישויות הקשריים.
  • מרווח מחזור החיים של האינדיקטור (metadata.interval): חלון התוקף המוגבל בזמן (start_time ו-end_time) שמגדיר מתי אינדיקטור איום פעיל ב-ECG.
  • התאמה אוטומטית של IoC: ממצא שנוצר על ידי המערכת כשאירוע אבטחה נכנס תואם לישות פעילה של אינדיקטור ב-ECG. הממצא מוצג בדף התאמות של IoC.
  • חיפוש רטרואקטיבי ב-YARA-L: חיפוש היסטורי לפי דרישה שמבצע כלל זיהוי YARA-L 2.0 על טלמטריה של אבטחה מ-30 הימים האחרונים.

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

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

התאמה אוטומטית של אינדיקטורים בזמן אמת

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

כללי קורלציה מותאמים אישית של YARA-L וחיפוש רטרואקטיבי

  • המטרה: צירוף ישויות של מודיעין איומים ב-ECG עם טלמטריה של כמה אירועים וסריקה של עד 30 ימים של נתונים היסטוריים באמצעות חיפושים רטרוספקטיביים.
  • ערך: זיהוי של מתקפות רב-שלביות וחשיפה של פשרות היסטוריות שהתרחשו לפני הוספת אינדיקטור לפידים של איומים.

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

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

  • הרשאות: כדי לנהל פידים של נתונים וכללי זיהוי של מחברים ב-Google SecOps (לדוגמה, Chronicle API Admin או Chronicle API Editor), צריכות להיות לכם הרשאות לניהול זהויות והרשאות גישה (IAM). לפרטים על התפקידים הנדרשים, אפשר לעיין במאמר הגדרת גישה לפיצ'רים.
  • בדיקת הסביבה: מוודאים שיש לכם מופע פעיל של Google SecOps ופרטי כניסה תקפים ל-API או כתובות URL של נקודות קצה של ספק מודיעין האיומים החיצוני (כמו MISP,‏ STIX/TAXII או מאגרי Cloud Storage).
  • הבדלים בין חיפוש לבין פונקציונליות של כללים: חיפוש ב-UDM מאפשר לבדוק רשומות של ישויות גולמיות שמאוחסנות ב-ECG, ללא קשר לחלון הפעיל שלהן. לעומת זאת, כללי זיהוי של YARA-L והתאמה אוטומטית בודקים רק אינדיקטורים שmetadata.interval כולל את חותמת הזמן של האירוע.
  • קידומות של לוחות בקרה ושדות חיפוש: כשמבצעים שאילתות על ישויות של מודיעין איומי סייבר בחיפוש UDM, בלוחות בקרה או בכללי YARA-L, משתמשים בקידומת graph.entity. לערכי אינדיקטורים (כמו graph.entity.ip) ובקידומת graph.metadata.threat. לשדות של שיוך איומים.

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

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

בחירת מנגנון להעברת פיד

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

  • מנתחים מובנים שמוגדרים כברירת מחדל: Google SecOps כולל מנתחים מובנים שמוגדרים כברירת מחדל עבור פלטפורמות רבות של מודיעין איומי סייבר. רשימה של מנתחי נתונים נתמכים שמסווגים בקטגוריה IOC מופיעה במאמר סוגי יומנים נתמכים ומנתחי נתונים שמוגדרים כברירת מחדל. בין הספקים הנתמכים: MISP,‏ ThreatConnect,‏ Intel471 ו-Cyjax.
  • ‫Feed Management API: אפשר להגדיר פידים במסוף Google SecOps או באמצעות Feed Management API כדי לשלוף באופן תקופתי אינדיקטורים מנקודות קצה חיצוניות של HTTPS,‏ Cloud Storage או Amazon S3.
  • ‫Ingestion API: אפשר לשלוח מטען ייעודי (payload) של ישויות שעברו ארגון מראש ישירות אל Google SecOps באמצעות Ingestion API.
  • סוכן Bindplane: איסוף והעברה של יומני אינדיקטורים מסביבות מקומיות או מסביבות ענן באמצעות סוכן Bindplane.
  • פונקציות של Cloud Run: אפשר לפרוס סקריפטים להזנת נתונים ללא שרת באמצעות פונקציות של Cloud Run כדי לאחזר אינדיקטורים מממשקי API חיצוניים (כמו STIX/TAXII או MISP) ולהזרים אותם ל-Google SecOps. פרטים נוספים זמינים במאמר בנושא שימוש בסקריפטים להעברת נתונים שנפרסו כפונקציות Cloud Run.
  • שילובים של תגובות ב-Google SecOps: הוספת אינדיקטורים באמצעות מחברים של Content Hub כדי לסנכרן רשימות של איומים כחלק מ-playbooks אוטומטיים. פרטים נוספים מופיעים במאמר בנושא שימוש במרכז התוכן.

הוספת פידים של מודיעין איומי סייבר

כדי להטמיע יומני אינדיקטורים מספק מודיעין האיומים שלכם ב-Google SecOps:

  1. פועלים לפי תהליך ההצטרפות לפורמט או לספק הספציפיים של פיד האיומים:

  2. מקצים את סוג היומן המתאים של IoC (כמו STIX, ‏ MISP_IOC,‏ CSV_CUSTOM_IOC או THREATCONNECT_IOC) לנתוני הפיד הנכנסים, כדי שמנתח ברירת המחדל יחלץ מאפייני אינדיקטור לשדות של ישויות UDM.

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

אכלוס ואימות של תרשים הקשר של הישות

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

מיפוי של נתונים מובנים לעומת נתונים לא מובנים

בהתאם לאופן שבו אתם שולחים נתוני מודיעין איומי סייבר ל-Google SecOps, פועלים לפי תהליך העבודה המתאים למיפוי השדות:

  • הטמעת נתונים מובנים: כששולחים רשומות של ישויות UDM שהוגדרו מראש ישירות באמצעות Ingestion API, צריך לעצב כל מטען ייעודי (payload) בהתאם לסכימת UDM Entity לפני ההטמעה.
  • הטמעת נתונים לא מובנים ונתונים חצי מובנים: כששולחים יומנים גולמיים (כמו CSV,‏ JSON,‏ STIX או CEF) באמצעות פידים, סוכן Bindplane או Forwarders, צריך להקצות מנתח ברירת מחדל מוכן מראש או ליצור מיפויים של שדות בהתאמה אישית באמצעות תוספי מנתח כדי לחלץ ערכי אינדיקטורים ולמפות אותם לשדות נדרשים של ישויות UDM.

מה הופך ישות ל-IoC

כדי שרשומה של ישות ב-ECG תזוהה כ-IoC שניתן לפעול לפיו על ידי כללי התאמה וזיהוי אוטומטיים, מנתח התוכן או מטען ה-API צריכים לאכלס את חמש קבוצות השדות הבאות ב-UDM:

  • סוג הישות (metadata.entity_type): סוג הישות של האינדיקטור הנתמך, כמו DOMAIN_NAME,‏ IP_ADDRESS,‏ FILE או URL.
  • סוג המקור (metadata.source_type): הסיווג של מקור הנתונים, שצריך להיות ENTITY_CONTEXT עבור פידים של מודיעין איומים שהלקוח מעביר.
  • מזהה הארטיפקט (entity.*): ערך האינדיקטור עצמו, כמו graph.entity.ip,‏ graph.entity.hostname,‏ graph.entity.domain.name,‏ graph.entity.file.sha256 (או md5 ו-sha1) או graph.entity.url.
  • מטא-נתונים של האיום (metadata.threat): מאפיינים הקשריים שמתארים את האיום, כולל threat_feed_name,‏ threat_name,‏ category,‏ severity ו-confidence.

  • מרווח זמן של מחזור החיים (metadata.interval):

    • ‫metadata.interval.start_time: חותמת הזמן שבה האינדיקטור הופך לפעיל.
    • ‫metadata.interval.end_time: חותמת הזמן שבה פג תוקף האינדיקטור.

הגדרות הסכימה מפורטות במאמרים רשימת השדות של UDM עבור Entity ו-EntityMetadata.

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

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Investigation (חקירה) > Search (חיפוש).

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

    • כתובת IP:

      graph.entity.ip = "<var>IP_ADDRESS</var>"

    • דומיין:

      graph.entity.hostname = "<var>DOMAIN_NAME</var>"

    • גיבוב (hash) של הקובץ (SHA-256):

      graph.entity.file.sha256 = "<var>SHA256_HASH</var>"

    • מוצר המקור:

      graph.metadata.source_product = "<var>SOURCE_PRODUCT_NAME</var>"

  3. לוחצים על חיפוש או מקישים על Enter.

  4. לוחצים על כרטיס הישות שמוחזר ומוודאים שהשדות threat ו-interval מכילים את המטא-נתונים הצפויים וחותמות זמן פעילות.

הצלבת נתוני טלמטריה וזיהוי איומים

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

הפעלה של התאמה אוטומטית של IoC

‫Google SecOps כולל מנוע התאמה אוטומטי שפועל באופן עצמאי מכללי זיהוי מותאמים אישית. כשנתוני הטלמטרייה של האירוע תואמים לאינדיקטור פעיל באק"ג:

  • התאמות שנוצרות על ידי המערכת: הפלטפורמה יוצרת באופן אוטומטי רשומה של התאמה ל-IoC בלי לדרוש תחזוקה של כללים מותאמים אישית.
  • התזמון המשוער של הפעולות אחרי ההטמעה (הערכה גסה):
    • אירועים בהזרמה: אחרי שאמצעי ההגנה מאכלס את ה-ECG (בדרך כלל 5 עד 15 דקות אחרי ההטמעה), Google SecOps מעריך אירועים בהזרמה ומציג התאמות בדף IoC matches תוך 5 עד 15 דקות.
    • אירועים היסטוריים: מנוע ההתאמה האוטומטי מעריך גם אינדיקטורים חדשים שהוזנו באופן רטרואקטיבי מול טלמטריה היסטורית במחזורי אצווה. התאמות ראשוניות מופיעות בדרך כלל תוך שעה עד 4 שעות, והמתאם ההיסטורי המלא מסתיים תוך 24 שעות.
  • החלת מרווחים: מנוע ההתאמה מעריך אירועים באופן מדויק ביחס לאותות פעילים, כאשר חותמת הזמן של האירוע נמצאת בטווח metadata.interval.

יצירת כללי קורלציה ב-YARA-L 2.0

כתיבת כללי זיהוי של YARA-L 2.0 כדי לצרף טלמטריה של אירועים (כמו חיבורים לרשת, שאילתות DNS או הפעלות של תהליכים) לישויות של אינדיקטורים ב-ECG. כללים מותאמים אישית מאפשרים לכם לשלב התאמות של אינדיקטורים עם ספי התנהגותיים, הקשר של נכסים ורשימות החרגות:

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Detection (זיהוי) > Rules & Detections (כללים וזיהויים) ואז לוחצים על New (חדש).
  2. בקטע events: של הכלל, מגדירים משתנה placeholder כדי לצרף שדה אירוע UDM (למשל $net.target.ip = $ip) לשדה הישות התואם של ECG (למשל $ioc.graph.entity.ip = $ip).

  3. מסננים את משתנה הישות לפי מאפייני איום (כמו $ioc.graph.metadata.threat.category) ומציינים חלון זמן של קורלציה בקטע match: (לדוגמה, $ip over 5m).

  4. לוחצים על שמירת כלל חדש.

הפעלת חיפוש רטרו כדי לזהות פשרות היסטוריות

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

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Detection (זיהוי) > Rules & Detections (כללים וזיהויים).
  2. מחפשים את הכלל המותאם אישית של מודיעין האיומים ברשימת הכללים.
  3. לוחצים על כדי לראות עוד אפשרויות לכללים ובוחרים באפשרות YARA-L Retrohunt.
  4. בתיבת הדו-שיח YARA-L Retrohunt, בוחרים את שעות ההתחלה והסיום של החיפוש ההיסטורי. מוודאים שטווח התאריכים שנבחר גדול או שווה לחלון ההתאמה שצוין בכלל.
  5. לוחצים על Run.

  6. פותחים את הכרטיסייה Detections (זיהויים) של הכלל כדי לעקוב אחרי ההתקדמות ולבדוק התאמות היסטוריות.

פרטים נוספים מופיעים במאמר בנושא הפעלת כלל על נתונים היסטוריים.

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

בדיקת הממצאים שנוצרו על ידי כללי התאמה אוטומטית וכללי קורלציה מותאמים אישית בתצוגות ייעודיות ב-Google SecOps.

בדיקת התאמות אוטומטיות בדף ההתאמות של IoC

כדי לבדוק התאמות אוטומטיות של אינדיקטורים:

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Detection (זיהוי) > IoC matches (התאמות של אינדיקטורים לפשרה).
  2. אפשר להשתמש באמצעי הסינון כדי לצמצם את התוצאות לפי סוג האינדיקטור (דומיינים, כתובות IP, גיבובים של קבצים או כתובות URL).
  3. כדי לפתוח את חלונית הפרטים של ההתאמה, שבה מוצגים:
    • נכסים פנימיים ושמות משתמשים משויכים.
    • חותמות הזמן של האירוע הראשון והאירוע האחרון שנצפו.
    • מקור פיד מודיעין האיומים ושיוך רמת הוודאות.
  4. לוחצים על View in UDM Search (הצגה בחיפוש UDM) כדי לבדוק את כל אירועי הטלמטריה הגולמיים שמשויכים לאינדיקטור.

מידע נוסף זמין במאמר צפייה ב-IoC באמצעות Applied Threat Intelligence.

מיון של התראות שמופעלות על ידי כללים בדפים 'התראות' ו'זיהויים'

זיהויים שנוצרו על ידי כללי YARA-L מותאמים אישית מופיעים בדפים התראות וזיהויים:

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Detection (זיהוי) > Alerts & IoCs (התראות ואינדיקטורים של פשרות) כדי לראות התראות על כללים שסודרו לפי עדיפות.
  2. לוחצים על שם ההתראה כדי לפתוח את הדף פרטי ההתראה ולבדוק את הטבלה זיהויים, שבה מפורטות שורות של אירועים מתואמים ומאפיינים של ישויות ב-ECG.
  3. בכללים שקטים (שבהם ההתראות מושבתות) או בחיפושים רטרוספקטיביים שהושלמו, פותחים את זיהוי > כללים וזיהויים, לוחצים על שם הכלל ובודקים את הכרטיסייה זיהויים.

התאמה בין אינדיקטורים מותאמים אישית לבין מרכז האיומים המתעוררים

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

  1. בתפריט הניווט של Google SecOps, בוחרים באפשרות Detection (זיהוי) > Emerging Threats (איומים מתפתחים).
  2. בודקים את הקמפיינים הפעילים של איומים ואת ההמלצות, ועוברים לחיפוש ב-UDM כדי לבדוק אם יש חפיפה בין האינדיקטורים מפידי האיומים המותאמים אישית לבין פעילות הקמפיין שנצפתה.

פרטים נוספים מופיעים במאמר סקירה כללית של מרכז האיומים המתעוררים.

גישה לנכסים ולהפניות מתקדמים

כשיוצרים כללי מודיעין איומי סייבר בהתאמה אישית, אפשר להשתמש בקטעי הקוד הבאים של YARA-L 2.0 ובמשאבי העזר.

חיבור יוצא לרשת שתואם לכתובת IP זדונית

הכלל הזה מבצע קורלציה בין אירועי NETWORK_CONNECTION יוצאים לבין אינדיקטורים פעילים של כתובות IP ב-ECG:

rule custom_ioc_network_connection {
  meta:
    author = "Security Operations"
    description = "Detects connections to IPs matching custom threat intel"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $net.metadata.event_type = "NETWORK_CONNECTION"
    $net.target.ip = $ip

    $ioc.graph.entity.ip = $ip
    $ioc.graph.metadata.threat.category = "SUSPICIOUS_NETWORK"

  match:
    $ip over 5m

  outcome:
    $risk_score = max(85)
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $principal_hostname = array_distinct($net.principal.asset.hostname)

  condition:
    $net and $ioc
}

שאילתת DNS שתואמת לדומיין זדוני

הכלל הזה מזהה בדיקות של NETWORK_DNS בדומיינים שסומנו כזדוניים בפידים של איומים שהועברו:

rule custom_ioc_malicious_domain_query {
  meta:
    author = "Security Operations"
    description = "Detects DNS queries for domains matching threat intel"
    severity = "MEDIUM"
    priority = "MEDIUM"

  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name = $domain

    $ioc.graph.entity.hostname = $domain

  match:
    $domain over 10m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $source_feed = array_distinct($ioc.graph.metadata.source_product)
    $client_ip = array_distinct($dns.principal.ip)

  condition:
    $dns and $ioc
}

התאמה של ביצוע תהליך לגיבוב (hash) של קובץ זדוני מסוג SHA-256

הכלל הזה מופעל כשאירוע PROCESS_LAUNCH תואם לגיבוב SHA-256 של קובץ זדוני ידוע שמאוחסן ב-ECG:

rule custom_ioc_malicious_file_execution {
  meta:
    author = "Security Operations"
    description = "Detects process launches matching malicious file hashes"
    severity = "CRITICAL"
    priority = "HIGH"

  events:
    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.target.process.file.sha256 = $sha256

    $ioc.graph.entity.file.sha256 = $sha256

  match:
    $sha256 over 5m

  outcome:
    $threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
    $file_path = array_distinct($process.target.process.file.full_path)
    $hostname = array_distinct($process.principal.asset.hostname)
    $user = array_distinct($process.principal.user.userid)

  condition:
    $process and $ioc
}

בלוגים של הקהילה ומקורות מידע נוספים

דוגמאות נוספות ליצירת כללי YARA-L ולקישור בין פידים מותאמים אישית של מודיעין איומים זמינות במקורות המידע הבאים של Google Cloud הקהילה:

פתרון בעיות

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

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

  • הטמעה ואינדוקס של חיפושים ב-UDM: בדרך כלל, אינדיקטורים חדשים שמוטמעים מופיעים בחיפוש ב-UDM תוך 2 עד 5 דקות. צריך להמתין לפחות 5 דקות אחרי הטמעת הפיד לפני שמתחילים לפתור בעיות שקשורות לרשומות של ישויות חסרות.
  • השהיה בהתאמה אוטומטית של IoC: אחרי שאינדיקטור מאכלס את ה-ECG, התאמות לאירועים נכנסים של סטרימינג מופיעות בדף IoC matches תוך 5 עד 15 דקות. בדרך כלל, התאמה רטרואקטיבית של נתונים היסטוריים מתבצעת תוך שעה עד 4 שעות (ועד 24 שעות להתאמה מלאה של נתונים היסטוריים).
  • חלון המתאם של גרף ההקשר של ישויות: כללי התאמה אוטומטית של IoC וכללי מתאם של YARA-L מעריכים אינדיקטורים רק בתוך חלון הפעילות שלהם, שהוא metadata.interval. מחוונים עם ערכי end_time שתוקפם פג לא יוצרים התאמות.
  • חלון החיפוש של Retrohunt: סריקות Retrohunt של YARA-L סורקות עד 30 ימים של טלמטריה היסטורית לכל הפעלה. הזמן שייקח לו להיות מוכן תלוי במורכבות הכלל ובזמינות של משאבי המערכת.

תיקון שגיאות

אפשר להשתמש בטבלה הזו כדי לאבחן ולפתור בעיות במהלך ההצטרפות למודיעין איומי סייבר וכתיבת כללי זיהוי.

שגיאה תיאור הבעיה תיקון
יומנים של IoC שלא עברו ניתוח סטטוס הפיד מראה נתונים נכנסים, אבל הניתוח של היומנים לישויות UDM נכשל. מוודאים שסוג יומן הפיד תואם למנתח (לדוגמה, STIX,‏ MISP_IOC או CSV_CUSTOM_IOC). בלוח הבקרה Data ingestion (העברת נתונים) בודקים אם יש שגיאות בסכימה הגולמית.
תוצאות חיפוש חסרות ב-UDM הניתוח של יומני האינדיקטורים מתבצע ללא שגיאות, אבל החיפוש ב-UDM לא מחזיר רשומות של ישויות. מוודאים שהשאילתה מכוונת לשדות graph.entity.* (כמו graph.entity.ip) ולא לשדות של אירועים udm.principal.*.
הכלל לא מופעל על סמך אינדיקטור מוכר האירוע והאינדיקטור קיימים בחיפוש UDM, אבל כלל YARA-L לא מפיק זיהויים. מוודאים שהתאריך והשעה של האירוע מופיעים בין metadata.interval.start_time ל-metadata.interval.end_time בסימן.
התראת שיטפון במהלך חיפוש רטרואקטיבי הפעלת חיפוש רטרו יוצרת מאות התראות ופניות כפולות ב-SOAR. לפני שמתחילים בחיפוש רטרואקטיבי, משביתים את המתג של ההתראות של הכלל. לפני שמפעילים מחדש את ההתראות בזמן אמת, כדאי לעיין בתוצאות הזיהוי בדף זיהויים.
נפח גבוה של תוצאות חיוביות שגויות אינדיקטורים רועשים מפעילים זיהויים בסורקים פנימיים תמימים או במארחים אדמיניסטרטיביים. מוסיפים לרול החרגה של רשימת הפניות (לדוגמה, not $net.principal.ip in %benign_scanner_ips) ודורשים הקשר של אירוע התנהגותי.

אימות ובדיקה

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

  1. פותחים את זיהוי > כללים וזיהויים ולוחצים על הכלל כדי לפתוח את עורך הכללים.
  2. לוחצים על בדיקת הכלל בחלונית התחתונה כדי להעריך את הכלל בהשוואה לנתוני אירועים היסטוריים עדכניים ולרכיבי ECG פעילים, בלי ליצור התראות או מקרים ב-SOAR.
  3. בודקים את הזיהויים של הבדיקות שהוחזרו כדי לוודא שהמשתנים של outcome (כמו $threat_name ו-$source_feed) מאוכלסים כצפוי.

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

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