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

נתמך ב:

Google SecOps SIEM

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

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

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

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

אימות 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: כדי להפעיל את הכללים האלה, צריך לבצע כמה פעולות במסוף Google Cloud .

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

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

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

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

חשוב: את השלבים הבאים צריך לבצע כמשתמש IAM בפרויקט שנבחר, שיש לו הרשאה לערוך את מטא-נתוני המופע של מכונה וירטואלית. לחשבון המשתמש צריכה להיות הרשאה setInstanceMetadata.

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

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

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

   1. מתחברים ל-Google SecOps.
   2. פותחים את הדף Curated Detections ולוחצים על Dashboard.
   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. פותחים את הדף Curated Detections ולוחצים על Dashboard.
   3. בודקים שהכלל ur_tst_Google Cloud_Cloud_DNS_Test_Rule הופעל ברשימת הזיהוי.

שלב 4. שליחת נתונים לכללים של Cloud Kubernetes Node Testing

חשוב: את השלבים הבאים צריך לבצע כמשתמש 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. פותחים את הדף Curated Detections ולוחצים על Dashboard.

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:

• מערכי נתונים וסוגי יומנים שנדרשים
• הפעלה והגדרה של ערכות כללים משופרות של CDIR SCC

מידע נוסף על ההתראות של 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."
   --role="roles/owner`"
   

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

   ההתראה Persistence: מתן הרשאות IAM חריגות של Security Command Center אמורה להיות מופעלת.

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

6. אמורה להופיע התראה של Google SecOps עם הכותרת Test SCC Alert: מתן הרשאות IAM חריגות לחשבון בדיקה.

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

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

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

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

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

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

     curl etd-malware-trigger.goog
   

   אחרי שמריצים את הפקודה הזו, אמורה להתקבל התראה ב-Security Command Center על תוכנות זדוניות: דומיין בעייתי.

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.
   • סוג גבולות הגזרה לגבולות גזרה רגילים (ברירת מחדל).
   • סוג ההגדרה לנאכף.

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. הפעולה הזו אמורה להפעיל את ההתראה התחמקות ממנגנוני הגנה: שינוי של היקף VPC Service Control ב-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.
   • ‫Dataset: הערך שמוגדר הוא 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'

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

הערה: את הבדיקה הזו צריך להריץ בדפדפן Chrome שמנוהל על ידי חשבון Chrome Enterprise.

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

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

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

שלב 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 הופעל ברשימת הזיהוי.

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

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

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

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

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

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

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

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

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

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

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

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

חשוב: את השלבים הבאים צריך לבצע כמשתמש IAM בחשבון שנבחר, שיש לו הרשאה לערוך את התגים של מופע EC2.

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, לוחצים על Detection (זיהוי) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו).
2. לוחצים על לוח הבקרה.
3. בודקים שהכלל AWS CloudTrail Test Rule הופעל ברשימת הזיהוי.

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

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

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

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

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

1. מתחברים ל-Google SecOps.
2. פתיחת הדף Curated Detections.
3. לוחצים על Rules & Detections (כללים וזיהויים) > Rule Sets (קבוצות כללים).
4. מרחיבים את הקטע Managed Detection Testing. יכול להיות שתצטרכו לגלול בדף.
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 הופעלו ברשימת הזיהוי.

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

שלב 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 עם מחרוזת צפויה וייחודית.

הערה: הבדיקה פועלת רק אם סוכן EDR או Sysmon מותקנים במכשיר Windows שנבדק.

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

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

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

שלב 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

לוח הבקרה Data Ingestion and Health ב-Google SecOps מאפשר לכם לראות מידע על הסוג, הנפח והתקינות של כל הנתונים שמוזנים ל-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. בוחרים באפשרות Managed Detection Testing (בדיקות מנוהלות של זיהוי איומים) > Office 365 Managed Detection Testing (בדיקות מנוהלות של זיהוי איומים ב-Office 365).

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

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

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

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

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

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

כלל בדיקה 1

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

Test Rule 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

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

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

שלב 3. הפעלת כללי הבדיקה המנוהלת של Okta

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

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

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

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

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

כלל בדיקה 1

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

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

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

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.