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

נתמך ב:

הזיהויים שנאספו ב-Google Security Operations כוללים קבוצה של כללי בדיקה שעוזרים לכם לוודא שהנתונים שנדרשים לכל קבוצת כללים הם בפורמט הנכון.

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

שם קבוצת הכללים תיאור
Google Cloud בדיקות זיהוי מנוהלות האימות מוודא ש Google Cloud הנתונים נבלעים בהצלחה ממכשירים שנתמכים על ידי הקטגוריה Cloud Threats.
מידע נוסף זמין במאמר אימות Google Cloud הטמעה של נתונים לקטגוריה Cloud Threats.
בדיקות גילוי מנוהלות ב-Chrome Enterprise האימות מוודא שהנתונים נקלטים בהצלחה ממכשירים שנתמכים על ידי הקטגוריה 'איומים ב-Chrome Enterprise'.
מידע נוסף זמין במאמר בנושא אימות של הכנסת נתונים לקטגוריה 'איומים' ב-Chrome Enterprise.
AWS Managed Detection Testing מאמת שהנתונים של AWS נבלעים בהצלחה ממכשירים שנתמכים על ידי הקטגוריה 'איומים בענן'.
מידע נוסף זמין במאמר אימות של בליעת נתוני AWS בקטגוריה 'איומים בענן'.
בדיקת זיהוי מנוהלת ב-Linux בודק שהנתונים נקלטים בהצלחה ממכשירים שנתמכים על ידי הקטגוריה Linux Threats (איומים ב-Linux).
מידע נוסף מופיע במאמר אימות קליטת נתונים עבור הקטגוריה Linux Threats.
בדיקת זיהוי מנוהלת ב-Windows האימות מוודא שהנתונים נקלטים בהצלחה ממכשירים שנתמכים על ידי קטגוריית האיומים ב-Windows.
מידע נוסף זמין במאמר אימות של הכנסת נתונים לקטגוריה 'איומים ב-Windows'.
בדיקה של זיהוי נתונים ב-Office 365 הבדיקה מוודאת שהנתונים מוזנים בצורה נכונה ובפורמט המתאים לשימוש בגלאים מוכנים מראש עבור נתונים מ-Office 365.
מידע נוסף זמין במאמר אימות הזנת נתונים לקטגוריה Office 365.
בדיקה של זיהוי נתונים ב-Okta מאמת שהנתונים מוטמעים כהלכה ובפורמט המתאים לשימוש בגלאים מוכנים מראש עבור נתוני Okta.
מידע נוסף מופיע במאמר בנושא אימות של הכנסת נתונים לקטגוריה 'איומים' ב-Okta.

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

אימות Google Cloud הטמעת הנתונים בקטגוריה Cloud Threats (איומים בענן)

הכללים האלה עוזרים לוודא שנתוני היומן מוזנים כמצופה ל-Google SecOps Curated Detections.

כדי לבדוק את הנתונים, פועלים לפי הכללים הבאים:

  • כלל Cloud Audit Metadata Testing: כדי להפעיל את הכלל הזה, מוסיפים מפתח מטא-נתונים מותאם אישית ייחודי וצפוי לכל מכונה וירטואלית ב-Compute Engine ששולחת נתונים ל-Google SecOps.

  • כלל Cloud DNS Testing: כדי להפעיל את הכלל הזה, מבצעים חיפוש DNS בדומיין (chronicle.security) מתוך כל מכונה וירטואלית שיש לה גישה לאינטרנט וששולחת נתוני יומן ל-Google SecOps.

  • כללי SCC Managed Detection Testing: כדי להפעיל את הכללים האלה, צריך לבצע כמה פעולות במסוף Google Cloud .

  • כלל Cloud Kubernetes Node Testing: כדי להפעיל את הכלל הזה, צריך ליצור פרויקט בדיקה ששולח נתוני יומן ל-Google SecOps, וליצור מאגר צמתים ייחודי באשכול קיים של Google Kubernetes Engine.

שלב 1. הפעלת כללי הבדיקה

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. לוחצים על Rules & Detections (כללים וזיהויים) > Rule Sets (קבוצות כללים).
  4. מרחיבים את הקטע בדיקות מנוהלות של זיהוי. יכול להיות שתצטרכו לגלול בדף.
  5. לוחצים על Google Cloud בדיקות מנוהלות של זיהוי ברשימה כדי לפתוח את דף הפרטים.
  6. מפעילים את האפשרויות Status (סטטוס) ו-Alerting (התראות) עבור הכללים של Cloud Managed Detection Testing (בדיקת זיהוי מנוהלת בענן).

שלב 2. שליחת נתונים לכלל Cloud Audit Metadata Testing

כדי להפעיל את הבדיקה, מבצעים את השלבים הבאים:

  1. בוחרים פרויקט בארגון.
  2. עוברים אל Compute Engine ובוחרים מכונה וירטואלית בפרויקט.
  3. במכונה הווירטואלית, לוחצים על Edit (עריכה) ומבצעים את השלבים הבאים בקטע Custom MetaData (מטא-נתונים מותאמים אישית):
    1. לוחצים על הוספת פריט.
    2. מזינים את הפרטים הבאים:
      • מקש: GCTI_ALERT_VALIDATION_TEST_KEY
      • ערך: works
    3. לוחצים על Save.

  4. כדי לוודא שההתראה הופעלה:

    1. מתחברים ל-Google SecOps.
    2. פותחים את הדף 'זיהויים שנבחרו בקפידה' ולוחצים על לוח בקרה.
    3. בודקים שהכלל ur_tst_Google Cloud_Cloud_Audit_Metadata הופעל ברשימת הזיהוי.

שלב 3. שליחת נתונים לכלל Cloud DNS Testing

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

כדי להפעיל את הבדיקה, מבצעים את השלבים הבאים:

  1. בוחרים פרויקט בארגון.
  2. עוברים אל Compute Engine ובוחרים מכונה וירטואלית בפרויקט.
    • אם מדובר במכונה וירטואלית של Linux, מוודאים שיש לכם גישה ל-Secure Shell‏ (SSH).
    • אם מדובר במכונה וירטואלית של Windows, צריך לוודא שיש לכם גישה ל-Remote Desktop Protocol ‏ (RDP).
  3. לוחצים על SSH (Linux) או על RDP (Microsoft Windows) כדי לגשת למכונה הווירטואלית.

  4. כדי לשלוח נתוני בדיקה, מבצעים את אחד מהשלבים הבאים:

    • מכונה וירטואלית של Linux: אחרי שמקבלים גישה למכונה הווירטואלית באמצעות SSH, מריצים אחת מהפקודות הבאות: nslookup chronicle.security או host chronicle.security

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

      • ‫sudo apt-get install dnsutils (ל-Debian/Ubuntu)
      • ‫dnf install bind-utils (ל-RedHat/CentOS)
      • yum install bind-utils

    • מכונה וירטואלית של Microsoft Windows: אחרי שתיגשו למכונה הווירטואלית באמצעות RDP, תעברו לדפדפן מותקן כלשהו ותנווטו אל https://chronicle.security.

  5. כדי לוודא שההתראה הופעלה:

    1. מתחברים ל-Google SecOps.
    2. פותחים את הדף 'זיהויים שנבחרו בקפידה' ולוחצים על לוח בקרה.
    3. בודקים שהכלל ur_tst_Google Cloud_Cloud_DNS_Test_Rule הופעל ברשימת הזיהוי.

שלב 4. שליחת נתונים לכללים של בדיקת צמתים ב-Cloud Kubernetes

חשוב: צריך לבצע את השלבים הבאים כמשתמש IAM בפרויקט שנבחר שיש לו גישה למשאבי Google Kubernetes Engine. למידע מפורט יותר על יצירת אשכולות אזוריים ומאגרי צמתים, אפשר לעיין במאמר בנושא יצירת אשכול אזורי עם מאגר צמתים של אזור יחיד. כללי הבדיקה האלה נועדו לאמת את הטמעת הנתונים מסוג היומן KUBERNETES_NODE.

כדי להפעיל את כללי הבדיקה, מבצעים את השלבים הבאים:

  1. יוצרים פרויקט בארגון בשם chronicle-kube-test-project. הפרויקט הזה משמש לבדיקה בלבד.
  2. עוברים לדף Google Kubernetes Engine ב Google Cloud מסוף
    .מעבר לדף Google Kubernetes Engine
  3. לוחצים על יצירה כדי ליצור אשכול אזורי חדש בפרויקט.
  4. מגדירים את האשכול בהתאם לדרישות הארגון.
  5. לוחצים על Add node pool (הוספת מאגר צמתים).
  6. נותנים למאגר הצמתים את השם kube-node-validation, ואז משנים את גודל המאגר לצומת אחד לכל אזור.
  7. מחיקת משאבי הבדיקה:
    1. אחרי שיוצרים את מאגר הצמתים kube-node-validation, מוחקים אותו.
    2. מוחקים את פרויקט הבדיקה chronicle-kube-test-project.

  8. מתחברים ל-Google SecOps.

  9. פותחים את הדף 'זיהויים שנבחרו בקפידה' ולוחצים על לוח בקרה.

  10. בודקים שהכלל tst_Google Cloud_Kubernetes_Node הופעל ברשימת הזיהוי.

  11. בודקים שהכלל tst_Google Cloud_Kubernetes_CreateNodePool הופעל ברשימת הזיהוי.

שלב 5. שליחת נתונים לבדיקה של כללים בבדיקת זיהוי בניהול SCC

בשלב הזה, בודקים שהממצאים של Security Command Center והנתונים שקשורים אליהם נקלטו בצורה נכונה ובפורמט הצפוי.

הכללים של SCC Managed Detection Testing בקטגוריה Managed Detection Testing מאפשרים לוודא שהנתונים שנדרשים לכללים של CDIR SCC Enhanced נשלחים ל-Google SecOps ובפורמט הנכון.

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

חשוב להשלים את הקטעים הבאים במסמך הזה שנדרשים להגדרת רישום ב Google Cloud שירותים, לאיסוף ממצאים של Security Command Center Premium ולשליחת ממצאים של Security Command Center אל Google SecOps:

מידע נוסף על ההתראות של Security Command Center שמתוארות בקטע הזה זמין במסמך של Security Command Center בנושא חקירה של איומים ותגובה לאיומים.

הפעלת כלל הבדיקה CDIR SCC Persistence

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

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

  2. כשהמופע החדש יהיה זמין, מקצים את Access Scope ל-Allow Full Access to all APIs.

  3. יוצרים חשבון שירות חדש עם הפרטים הבאים:

    • מגדירים את שם חשבון השירות לערך scc-test.
    • מגדירים את מזהה חשבון השירות לערך scc-test.
    • אופציונלי: מזינים תיאור לחשבון השירות.

    במאמר יצירת חשבונות שירות מוסבר איך יוצרים חשבונות שירות.

  4. מתחברים באמצעות SSH למכונת הבדיקה שנוצרה בשלב הקודם, ואז מריצים את הפקודה הבאה gcloud:

    gcloud projects add-iam-policy-binding PROJECT_NAME
--member="serviceAccount:scc-test@PROJECT_NAME.iam.gserviceaccount.com"
--role="roles/owner`"

    מחליפים את PROJECT_NAME בשם הפרויקט שבו פועלת מכונת Compute Engine ושבו נוצר חשבון scc-test.

    ההתראה Persistence: IAM Anomalous Grant של Security Command Center אמורה להיות מופעלת.

  5. מתחברים ל-Google SecOps ופותחים את הדף Alerts & IOCs.

  6. אמורה להופיע התראה של Google SecOps בשם Test SCC Alert: IAM Anomalous Grant given to test account.

  7. פותחים את מסוף Google Cloud ומבצעים את הפעולות הבאות:

    • מסירים את הגישה לחשבון הבדיקה של scc-test מ-IAM וממסוף Admin.
    • מוחקים את חשבון השירות באמצעות הפורטל Service Accounts (חשבונות שירות).
    • מוחקים את המופע של מכונה וירטואלית שיצרתם.

הפעלת כלל הבדיקה של תוכנות זדוניות ב-CDIR SCC

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

  1. במסוף Google Cloud , מתחברים באמצעות SSH לכל מכונה וירטואלית שמותקנת בה הפקודה curl.

  2. מריצים את הפקודה הבאה:

      curl etd-malware-trigger.goog

    אחרי שמריצים את הפקודה הזו, אמור להתקבל התראה של Security Command Center‏ Malware: Bad Domain (תוכנות זדוניות: דומיין בעייתי).

  3. נכנסים ל-Google SecOps ופותחים את הדף Alerts & IOCs.

  4. מוודאים שמוצגת התראה של Google SecOps עם הכותרת Test SCC Alert: Malware Bad Domain.

הפעלת כלל הבדיקה CDIR SCC Defense Evasion

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

  1. נכנסים ל- Google Cloud Console באמצעות חשבון שיש לו גישה ברמת הארגון לשינוי VPC Service Control Perimeters.

  2. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    מעבר אל VPC Service Controls

  3. לוחצים על +היקף חדש ומגדירים את השדות הבאים בדף פרטים:

    • כותרת ההיקף: scc_test_perimeter.
    • ‫Perimeter Type (סוג ההיקף) ל-Regular perimeter (default) (היקף רגיל (ברירת מחדל)).
    • סוג ההגדרה לאכיפה.

  4. בחלונית הניווט הימנית, בוחרים באפשרות 3 שירותים מוגבלים.

  5. בתיבת הדו-שיח Specify services to restrict (ציון שירותים להגבלה), בוחרים באפשרות Google Compute Engine API (ה-API של Google Compute Engine) ואז לוחצים על Add Google Compute Engine API (הוספת ה-API של Google Compute Engine).

  6. בחלונית הניווט הימנית, לוחצים על יצירת היקף.

  7. כדי לשנות את גבולות הגזרה, עוברים לדף VPC Service Perimeters. מידע מפורט יותר על גישה לדף הזה זמין במאמר רשימה ותיאור של גבולות גזרה לשירות.

  8. לוחצים על scc_test_perimeter ואז על עריכת ההיקף.

  9. בקטע שירותים מוגבלים, לוחצים על סמל המחיקה כדי להסיר את השירות Google Compute Engine API. הפעולה הזו אמורה להפעיל את ההתראה Defense Evasion: Modify VPC Service Control Perimeter ב-SCC.

  10. נכנסים ל-Google SecOps ופותחים את הדף Alerts & IOCs.

  11. מוודאים שמוצג לכם התראה של Google SecOps עם הכותרת Test SCC Alert: Modify VPC Service Control Test Alert.

הפעלת כלל הבדיקה של זליגת מידע ב-SCC ב-CDIR

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

  1. במסוף Google Cloud , עוברים אל Google Cloud פרויקט ופותחים את BigQuery.

    כניסה ל-BigQuery

  2. יוצרים קובץ CSV עם הנתונים הבאים ושומרים אותו בספריית הבית:

    column1, column2, column3
data1, data2, data3
data4, data5, data6
data7, data8, data9

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

  4. מגדירים את ההגדרות הבאות ולוחצים על יצירת מערך נתונים:

    • הערך של Dataset ID הוא scc_test_dataset.
    • סוג המיקום מוגדר כמספר אזורים.
    • Enable Table expiration (הפעלת תפוגה של טבלה): לא בוחרים באפשרות הזו.

    מידע מפורט יותר על יצירת מערך נתונים זמין במאמר יצירת מערכי נתונים ב-BigQuery.

  5. בסרגל הניווט שמימין, משמאל לסמל scc_test_dataset, לוחצים על הסמל ואז בוחרים באפשרות יצירת טבלה.

  6. יוצרים טבלה ומגדירים את ההגדרות הבאות:

    • יצירת טבלה מ: בוחרים באפשרות העלאה.
    • בחירת קובץ: עוברים אל ספריית הבית ובוחרים את קובץ ה-CSV שיצרתם קודם.
    • פורמט הקובץ: בוחרים באפשרות CSV.
    • מערך הנתונים: הערך שמוגדר הוא css_test_dataset.
    • סוג הטבלה: מגדירים את האפשרות טבלה מקורית.

  7. מאשרים את הגדרות ברירת המחדל של כל שאר השדות ולוחצים על יצירת טבלה.

    מידע נוסף על יצירת טבלה זמין במאמר יצירה ושימוש בטבלאות.

  8. ברשימת המקורות, בוחרים את הטבלה css_test_dataset, לוחצים על שאילתה ובוחרים באפשרות בכרטיסייה חדשה.

  9. מריצים את השאילתה הבאה:

    SELECT * FROM TABLE_NAME LIMIT 1000`

    מחליפים את TABLE_NAME בשם הטבלה המוגדר במלואו.

  10. אחרי שהשאילתה מופעלת, לוחצים על שמירת התוצאות ואז בוחרים באפשרות CSV ב-Google Drive. הפעולה הזו אמורה להפעיל את ההתראה Exfiltration: BigQuery Exfiltration to Google Drive ב-Security Command Center. הממצא ב-Security Command Center צריך להישלח ל-Google SecOps ולהפעיל התראה ב-Google SecOps.

  11. מתחברים ל-Google SecOps ופותחים את הדף Alerts & IOCs.

  12. מוודאים שמופיעה התראה של Google SecOps עם הכותרת Test SCC Alert: BigQuery Exfiltration to Google Drive.

שלב 6. השבתת כללי הבדיקה

בסיום, משביתים את הכללים של Google Cloud בדיקת זיהוי מנוהלת.

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. משביתים את האפשרויות סטטוס והתראות עבור הכללים של Google Cloud בדיקת זיהוי מנוהלת.

אימות של הכנסת נתונים לקטגוריה Chrome Enterprise Threats

הכלל Chrome Enterprise Test בודק שהרישום ביומן של Chrome Enterprise פועל בצורה תקינה עבור גלאים מוכנים מראש של Google SecOps. בבדיקה הזו נעשה שימוש בכתובת URL לבדיקת הגלישה הבטוחה, שאמורה להציג אזהרה מפני פישינג.

שלב 1. הפעלת כללי הבדיקה

כדי להפעיל את כללי הבדיקה:

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. מרחיבים את הקטע בדיקות מנוהלות של זיהוי. יכול להיות שתצטרכו לגלול בדף.
  4. ברשימה, לוחצים על Chrome Enterprise Managed Detection Testing כדי לפתוח את דף הפרטים.
  5. מפעילים את האפשרויות סטטוס והתראות עבור הכללים של בדיקת זיהוי מנוהלת של Chrome Enterprise.

שלב 2. שליחת נתוני בדיקה מדפדפן Chrome מנוהל

כדי להפעיל את כלל הבדיקה של Chrome Enterprise:

  1. פותחים דפדפן Chrome שמנוהל על ידי חשבון ארגוני ב-Chrome Enterprise.
  2. פותחים כרטיסייה חדשה ועוברים אל כתובת ה-URL לבדיקה של גלישה בטוחה. אמורה להופיע הודעת אזהרה.
  3. סוגרים את הדפדפן.

שלב 3. אימות שהופעלה התראה

מוודאים שהגישה לכתובת ה-URL של הבדיקה של הגלישה הבטוחה הפעילה את הכלל tst_chrome_enterprise_phishing_url ב-Google SecOps. המשמעות היא שהרישום ביומן של Chrome Enterprise שולח נתונים, כצפוי.

כדי לאמת את ההתראה ב-Google SecOps, מבצעים את הפעולות הבאות:

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. לוחצים על מרכז בקרה.
  4. מוודאים שהכלל tst_chrome_enterprise_phishing_url הופעל ברשימת הזיהוי.

שלב 4. השבתת כללי הבדיקה

אחרי שמסיימים את הבדיקה, משביתים את הכללים של בדיקת זיהוי מנוהלת ב-Chrome Enterprise:

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. משביתים את האפשרויות סטטוס והתראות בכללי הבדיקה של זיהוי מנוהל ב-Chrome Enterprise.

אימות של הכנסת נתונים מ-AWS לקטגוריה Cloud Threats

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

  • למשתמש שמפעיל את הכללים האלה במנוע הזיהוי צריכה להיות הרשאת ה-IAM‏ curatedRuleSetDeployments.batchUpdate.
  • למשתמש שמבצע את השלבים לשליחת נתונים של AWS צריכות להיות הרשאות AWS IAM לעריכת התגים של מכונת EC2 בחשבון שנבחר. למידע נוסף על תיוג מכונות EC2, אפשר לעיין במסמך AWS Tag your Amazon EC2 resources.

הפעלת כללי הבדיקה של AWS Managed Detection Testing

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

אימות לכך שפעולות תג ב-AWS מפעילות את כלל הבדיקה

כדי לוודא שפעולות התג ב-AWS מפעילות את קבוצת הכללים, מבצעים את השלבים הבאים.

שלב 1. יצירת אירוע ביומן ב-AWS.

  1. בוחרים חשבון בסביבת AWS.
  2. עוברים אל לוח הבקרה של EC2 ובוחרים מופע בחשבון.
  3. ב-EC2 Instance, לוחצים על Actions (פעולות) > Instance Settings (הגדרות של Instance), ומבצעים את הפעולות הבאות בקטע Manage Tags (ניהול תגים):
    1. לוחצים על הוספת תג חדש.
    2. הזן את פריטי המידע הבאים:
    3. מקרא: GCTI_ALERT_VALIDATION_TEST_KEY
    4. ערך: works
    5. לוחצים על Save.

מידע מפורט יותר זמין במאמר הוספה או הסרה של תגים של מופעי EC2.

שלב 2. מוודאים שההתראות לבדיקה מופעלות.

אחרי שמבצעים את המשימה בשלב הקודם, מוודאים שהכלל AWS CloudTrail Test Rule מופעל. ההודעה הזו מציינת שיומני CloudTrail נרשמו ונשלחו ל-Google SecOps כמצופה. כדי לאמת את ההתראה, מבצעים את השלבים הבאים:

  1. ב-Google SecOps, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו).
  2. לוחצים על מרכז בקרה.
  3. ברשימת הזיהויים, בודקים שהופעל הכלל tst_AWS_Cloud_Trail_Tag.

אימות של הפעלת כללי בדיקה על ידי ממצאים לדוגמה ב-AWS GuardDuty

כדי לוודא שההתראות של GuardDuty יפעלו כמצופה בסביבה שלכם, אתם יכולים לשלוח ממצאי דוגמה של GuardDuty אל Google SecOps.

שלב 1. יצירת נתונים לדוגמה של ממצאים ב-GuardDuty.

  1. עוברים לדף הבית של מסוף AWS.
  2. בקטע Security, Identity, and Compliance (אבטחה, זהות ותאימות), פותחים את GuardDuty.
  3. עוברים אל ההגדרות של GuardDuty.
  4. לוחצים על יצירת ממצאים לדוגמה.

למידע נוסף על יצירת ממצאים לדוגמה ב-GuardDuty, ראו יצירת ממצאים לדוגמה ב-GuardDuty.

שלב 2. מוודאים שהתראות הבדיקה הופעלו.

  1. ב-Google SecOps, לוחצים על זיהוי > כללים וזיהויים כדי לפתוח את הדף 'זיהויים שנאספו'.
  2. לוחצים על מרכז בקרה.
  3. בודקים שהכלל AWS CloudTrail Test Rule הופעל ברשימת הזיהוי.

השבתת קבוצות הכללים של AWS Managed Detection Testing

  1. ב-Google SecOps, לוחצים על זיהוי > כללים וזיהויים כדי לפתוח את הדף 'זיהויים שנאספו'.
  2. בוחרים בכללים Managed Detection Testing > AWs Managed Detection Testing.
  3. משביתים את האפשרויות סטטוס והתראות בכללים כללי ומדויק.

אימות הטמעת נתונים לקטגוריה Linux Threats

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

שלב 1. הפעלת כללי הבדיקה

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. לוחצים על Rules & Detections (כללים וזיהויים) > Rule Sets (קבוצות כללים).
  4. מרחיבים את הקטע בדיקות מנוהלות של זיהוי. יכול להיות שתצטרכו לגלול בדף.
  5. ברשימה, לוחצים על Linux Managed Detection Testing כדי לפתוח את דף הפרטים.
  6. מפעילים את האפשרויות Status (סטטוס) ו-Alerting (התראות) עבור הכללים של Linux Managed Detection Testing (בדיקת זיהוי מנוהלת ב-Linux).

שלב 2. שליחת נתוני בדיקה ממכשיר Linux

כדי להפעיל את כללי הבדיקה של Linux Managed Detection Testing, פועלים לפי השלבים הבאים:

  1. גישה לכל מכשיר Linux שבו נשלחים נתונים אל Google SecOps.
  2. פותחים ממשק שורת פקודה חדש של Linux Bash בתור משתמש כלשהו.

  3. מזינים את הפקודה הבאה ומקישים על Enter:

    /bin/echo hello_chronicle_world!

הערה: צריך להשתמש בקובץ הבינארי echo ולא בפקודה המובנית echo של מעטפת Linux.

  1. מזינים את הפקודה הבאה ומקישים על Enter:

    sudo useradd test_chronicle_account

  2. מסירים את חשבון הבדיקה שנוצר בשלב הקודם. מריצים את הפקודה הבאה:

    sudo userdel test_chronicle_account

  3. מזינים את הפקודה הבאה ומקישים על Enter:

    su

  4. כשמתבקשים להזין את הסיסמה, מזינים מחרוזת אקראית כלשהי. שימו לב שההודעה su: Authentication failure מוצגת.

  5. סוגרים את חלון Bash.

שלב 3. בדיקה אם ההתראות הופעלו ב-Google SecOps

מוודאים שהפקודה הפעילה את הכללים tst_linux_echo,‏ tst_linux_failed_su_login ו-tst_linux_test_account_creation ב-Google SecOps. המשמעות היא שהיומנים של Linux נכתבים ונשלחים כמצופה. כדי לאמת את ההתראה ב-Google SecOps, מבצעים את השלבים הבאים:

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. לוחצים על מרכז בקרה.

  4. מוודאים שהכללים tst_linux_echo,‏ tst_linux_failed_su_login ו-tst_linux_test_account_creation הופעלו ברשימת הזיהוי.

שלב 4. השבתת כללי הבדיקה

כשמסיימים, משביתים את הכללים של בדיקת זיהוי מנוהלת ב-Linux.

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. משביתים את האפשרויות סטטוס והתראות בכללי Linux Managed Detection Testing.

אימות של הכנסת נתונים לקטגוריה Windows Threats

הכלל Windows Echo Test Rule מוודא שהרישום ביומן של מיקרוסופט Windows פועל בצורה תקינה עבור גלאים מוכנים מראש של Google SecOps. הבדיקה כוללת שימוש בשורת הפקודה בסביבת Microsoft Windows כדי להריץ את הפקודה echo עם מחרוזת צפויה וייחודית.

אפשר להריץ את הבדיקה כשמחוברים כמשתמש שיש לו גישה לשורת הפקודה של Windows.

שלב 1. הפעלת כללי הבדיקה

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. מרחיבים את הקטע בדיקות מנוהלות של זיהוי. יכול להיות שתצטרכו לגלול בדף.
  4. לוחצים על Windows Managed Detection Testing ברשימה כדי לפתוח את דף הפרטים.
  5. מפעילים את האפשרויות סטטוס והתראות עבור הכללים של בדיקת זיהוי מנוהלת ב-Windows.

שלב 2. שליחת נתוני בדיקה ממכשיר Windows

כדי להפעיל את כלל בדיקת ההד ב-Windows, מבצעים את השלבים הבאים:

  1. גישה לכל מכשיר שמייצר נתונים שצריך לשלוח אל Google SecOps.
  2. פותחים חלון חדש של שורת הפקודה של Microsoft Windows כמשתמש כלשהו.

  3. מזינים את הפקודה הבאה (לא משנה אם האותיות קטנות או גדולות) ואז מקישים על Enter:

    cmd.exe /c "echo hello_chronicle_world!"

  4. סוגרים את חלון שורת הפקודה.

שלב 3. אימות שהופעלה התראה

מוודאים שהפקודה הפעילה את הכלל tst_Windows_Echo ב-Google SecOps. ההודעה הזו מציינת שהרישום ביומן של Microsoft Windows שולח נתונים כמצופה. כדי לאמת את ההתראה ב-Google SecOps, מבצעים את השלבים הבאים:

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. לוחצים על מרכז בקרה.

  4. מוודאים שהכלל tst_Windows_Echo הופעל ברשימת הזיהוי.

    הערה: יהיה עיכוב קל עד שההתראה תוצג ב-Google SecOps.

שלב 4. השבתת כללי הבדיקה

בסיום, משביתים את הכללים של בדיקת זיהוי מנוהלת ב-Windows.

  1. מתחברים ל-Google SecOps.
  2. פותחים את הדף Curated Detections.
  3. משביתים את האפשרויות סטטוס והתראות בכללי Windows Managed Detection Testing.

אימות של הכנסת נתונים לקטגוריית הנתונים של Office 365

מוודאים שהנתונים מוזנים בצורה נכונה ובפורמט המתאים לשימוש בזיהויים שנאספו מנתונים של Office 365.

שלב 1. הטמעת נתונים מ-Office 365

כדי לקבל כיסוי מקסימלי של הכללים, צריך להטמיע נתונים מכל מקור נתונים שמפורט בהוראות ההטמעה של Google SecOps. מידע נוסף על הטמעת נתונים בשירותי Office 365 זמין במאמר איסוף יומנים של Microsoft Office 365.

שלב 2. אימות ההטמעה של נתונים מ-Office 365

ב-Google SecOps לוח הבקרה Data Ingestion and Health אפשר לראות מידע על הסוג, הנפח והתקינות של כל הנתונים שמוזנים ל-Google SecOps באמצעות תכונות ההזנה של SIEM.

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

שלב 3. הפעלה של כללי הבדיקה של Azure Managed Detection Testing

  1. ב-Google SecOps, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו) ואת קבוצות הכללים.

  2. בוחרים באפשרות בדיקות מנוהלות של זיהוי > בדיקות מנוהלות של זיהוי ב-Office 365.

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

שלב 4. שליחת נתונים של פעולות משתמשים כדי להפעיל את כללי הבדיקה

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

כדי ליצור כלל לתיבת הדואר הנכנס ב-Outlook 365, אפשר להשתמש בתכונה Rules (כללים) בקטע Mail (דואר). אפשר גם ליצור כלל על ידי לחיצה ימנית על אימייל.

שלב 5. יצירת כלל לתיבת הדואר הנכנס באמצעות התכונה 'כללים'

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

כלל בדיקה 1

  1. לוחצים על אימייל ובוחרים באפשרות כללים.
  2. מזינים GoogleSecOpsTest בשם הכלל.
  3. בוחרים תנאי מהרשימה.
  4. בוחרים פעולה מהרשימה.
  5. לוחצים על הוספת תנאי או על הוספת פעולה כדי להוסיף עוד תנאים או פעולות לפי הצורך.
  6. לוחצים על OK.

כלל בדיקה 2

  1. עוברים אל SharePoint או אל OneDrive.
  2. בסרגל החיפוש, מזינים GoogleSecOpsTest.

אימות התוצאות

כדי לוודא שהתראות נוצרות ב-Google SecOps:

  1. ב-Google SecOps, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו).
  2. לוחצים על מרכז בקרה.
  3. ברשימת הזיהויים, מוודאים שהופעלו הכללים הבאים:
    • tst_o365_email.yl2
    • tst_of65_sharepoint_onedrive.yl2
  4. אחרי שמוודאים שהנתונים נשלחים והכללים מופעלים, משביתים את כלל תיבת הדואר הנכנס שנוצר בTest Rule 1.

אימות של העברת נתונים לקטגוריית האיומים ב-Okta

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

שלב 1. הטמעת נתוני Okta

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

שלב 2. אימות ההטמעה של נתוני Okta

ב-Google SecOps לוח הבקרה Data Ingestion and Health אפשר לראות מידע על הסוג, הנפח והתקינות של כל הנתונים שמוזנים ל-Google SecOps באמצעות תכונות ההזנה של SIEM.

אפשר גם להשתמש בכללי בדיקה של Okta Managed Detection כדי לוודא שהנתונים של Office 365 נקלטים. אחרי שמגדירים את ההטמעה, מפעילים את כללי הבדיקה על ידי ביצוע פעולות ב-Office 365. הכללים האלה מבטיחים שהנתונים ייקלטו בצורה נכונה ויהיו בפורמט המתאים לשימוש בגלאים מוכנים מראש עבור נתוני Office 365.

שלב 3. הפעלת כללי הבדיקה של Okta Managed Detection

  1. ב-Google SecOps, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו) ואת קבוצות הכללים.

  2. בוחרים באפשרות בדיקות מנוהלות של זיהוי > בדיקות מנוהלות של זיהוי ב-Office 365.

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

שלב 4. שליחת נתונים של פעולות משתמשים כדי להפעיל את כללי הבדיקה

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

כלל בדיקה 1

  1. ניגשים לכתובת ה-URL של הדייר ב-Okta.

  2. בשדה שם משתמש, מזינים GoogleSecOpsTest.

  3. בשדה סיסמה, מזינים מחרוזת כלשהי.

  4. לוחצים על כניסה.

אימות התוצאות

כדי לוודא שהתראות נוצרות ב-Google SecOps: ‫1. ב-Google SecOps, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו). 1. לוחצים על מרכז בקרה. 1. ברשימת הזיהויים, מוודאים שהופעלו הכללים הבאים: * Okta Unknown User Login Test (tst_okta_login_by_unknown_user.yl2) דרושה לך עזרה נוספת? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.