איומים בענן

נתמך ב:

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

תיאורים של קבוצות כללים

קבוצות הכללים הבאות זמינות בקטגוריה Cloud Threats (איומים בענן).

הקיצור CDIR מייצג Cloud Detection, Investigation, and Response (זיהוי איומים בענן, חקירה ותגובה).

גלאים מוכנים מראש ל Google Cloud נתונים

Google Cloud ערכות כללים עוזרות לזהות איומים בסביבות Google Cloud באמצעות נתונים של אירועים והקשר, והן כוללות את ערכות הכללים הבאות:

  • פעולת אדמין: פעילות שמשויכת לפעולות אדמין, שנחשבת לחשודה אבל יכולה להיות לגיטימית בהתאם לשימוש בארגון.
  • ‫CDIR SCC Enhanced Exfiltration: מכיל כללים מודעים-הקשר שמבצעים קורלציה בין ממצאי חילוץ נתונים ב-Security Command Center לבין מקורות יומנים אחרים, כולל יומנים של Cloud Audit Logs, הקשר של Sensitive Data Protection, הקשר של BigQuery ויומני הגדרות שגויות של Security Command Center.
  • ‫CDIR SCC Enhanced Defense Evasion: מכיל כללים מודעים-הקשר שמתאימים בין תוצאות של Security Command Center Evasion או Defense Evasion לבין נתונים ממקורות נתונים אחרים שלGoogle Cloud , כולל יומני ביקורת של Cloud.
  • ‫CDIR SCC Enhanced Malware: מכיל כללים מודעים-הקשר שמבצעים קורלציה בין ממצאי תוכנות זדוניות ב-Security Command Center לבין נתונים, כולל מקרים של כתובות IP ודומיינים וציוני השכיחות שלהם, בנוסף למקורות נתונים אחרים, כולל יומנים של Cloud DNS.
  • ‫CDIR SCC Enhanced Persistence: מכיל כללים מודעים-הקשר שמבצעים קורלציה בין ממצאי Persistence של Security Command Center לבין נתונים ממקורות, כולל יומני Cloud DNS ויומני ניתוח IAM.
  • ‫CDIR SCC Enhanced Privilege Escalation: מכיל כללים מודעים-הקשר שמבצעים קורלציה בין ממצאי העלאת הרשאות ב-Security Command Center לבין נתונים מכמה מקורות נתונים אחרים, כולל יומני ביקורת של Cloud.
  • ‫CDIR SCC Credential Access: מכיל כללים שמתחשבים בהקשר ומבצעים קורלציה בין תוצאות של Credential Access ב-Security Command Center לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני הביקורת של Cloud
  • ‫CDIR SCC Enhanced Discovery: מכיל כללים מודעים-הקשר שמתאימים בין ממצאי הסלמה של Discovery ב-Security Command Center לבין נתונים ממקורות כמו Google Cloud שירותים ויומני ביקורת של Cloud.
  • ‫CDIR SCC Brute Force: מכיל כללים שמתאימים להקשר ומבצעים קורלציה בין ממצאי הסלמה של Security Command Center Brute Force לבין נתונים, כולל יומנים של Cloud DNS.
  • ‫CDIR SCC Data Destruction: מכיל כללים מודעים-הקשר שמתאמים בין ממצאי הסלמה של השמדת נתונים ב-Security Command Center לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני הביקורת של Cloud.
  • ‫CDIR SCC Inhibit System Recovery: מכיל כללים מודעים-הקשר שיוצרים קורלציה בין ממצאים של Security Command Center Inhibit System Recovery לבין נתונים מכמה מקורות נתונים אחרים, כולל יומני ביקורת של Cloud.
  • ‫CDIR SCC Execution: מכיל כללים מודעים-הקשר שמתאימים בין תוצאות של Security Command Center Execution לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני הביקורת של Cloud.
  • ‫CDIR SCC Initial Access: מכיל כללים מודעים-הקשר שיוצרים קורלציה בין תוצאות של Security Command Center בנושא גישה ראשונית לבין נתונים מכמה מקורות נתונים אחרים, כולל יומני ביקורת של Cloud.
  • ‫CDIR SCC Impair Defenses: מכיל כללים מודעים-הקשר שיוצרים קורלציה בין תוצאות של 'החלשת אמצעי ההגנה' ב-Security Command Center לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני ביקורת של Cloud.
  • CDIR SCC Impact: מכיל כללים שמזהים ממצאים מסוג Impact מ-Security Command Center עם סיווג חומרה Critical,‏ High,‏ Medium ו-Low.
  • ‫CDIR SCC Cloud IDS: מכיל כללים שמזהים ממצאים של המערכת לגילוי חדירות של Google Cloud מ-Security Command Center עם סיווג חומרה קריטי, גבוה, בינוני ונמוך.
  • ‫CDIR SCC Cloud Armor: מכיל כללים שמזהים תוצאות של Google Cloud Armor מ-Security Command Center.
  • CDIR SCC Custom Module: מכיל כללים שמזהים ממצאים של מודול מותאם אישית של Event Threat Detection מ-Security Command Center.
  • ‫Cloud Hacktool: פעילות שזוהתה מפלטפורמות ידועות של אבטחה התקפית או מכלי תקיפה או תוכנה שנעשה בהם שימוש בטבע על ידי גורמי איום שמכוונים ספציפית למשאבי ענן.
  • ‫Cloud SQL Ransom: מזהה פעילות שקשורה להעברה לא מורשית או לדרישת כופר על נתונים במסדי נתונים של Cloud SQL.
  • Kubernetes Suspicious Tools: זיהוי התנהגות של סיור וניצול של כלי Kubernetes בקוד פתוח.
  • ניצול לרעה של RBAC ב-Kubernetes: זיהוי פעילות ב-Kubernetes שקשורה לניצול לרעה של בקרת גישה מבוססת-תפקידים (RBAC) בניסיון להרחבת הרשאות או לתנועה לרוחב.
  • פעולות רגישות שקשורות לאישורים של Kubernetes: זיהוי של אישורים של Kubernetes ופעולות של בקשות לחתימה על אישורים (CSR) שיכולות לשמש ליצירת התמדה או להעלאת הרשאות.
  • שימוש לרעה ב-IAM: פעילות שקשורה לשימוש לרעה בתפקידים ובהרשאות ב-IAM, שעשויה להוביל להעלאת רמת ההרשאות או לתנועה לרוחב בתוך פרויקט נתון ב-Cloud או בארגון ב-Cloud.
  • Potential Exfil Activity: זיהוי פעילות שקשורה לזליגת נתונים פוטנציאלית.
  • התחזות למשאב: זיהוי Google Cloud משאבים שנוצרו עם שמות או מאפיינים של משאב אחר או סוג משאב אחר. יכול להיות שהשימוש הזה נועד להסוות פעילות זדונית שמתבצעת על ידי המשאב או בתוכו, במטרה להציג אותו כלגיטימי.
  • איומים בלי שרת : זיהוי פעילות שקשורה לפגיעה פוטנציאלית במשאבים בלי שרת או לניצול לרעה שלהם ב- Google Cloud, כולל פונקציות Cloud Run ו-Cloud Run.
  • שיבוש בשירות: זיהוי פעולות הרסניות או משבשות, שאם יבוצעו בסביבת ייצור מתפקדת, עלולות לגרום להשבתה משמעותית. ההתנהגות שזוהתה נפוצה וסביר להניח שהיא לא מזיקה בסביבות בדיקה ופיתוח.
  • התנהגות חשודה: פעילות שנחשבת ללא שכיחה ולחשודה ברוב הסביבות.
  • שינוי חשוד בתשתית: זיהוי שינויים בתשתית הייצור שתואמים לטקטיקות ידועות של התמדה
  • החלשת ההגדרה: פעילות שקשורה להחלשה או להורדה של רמת האבטחה של אמצעי בקרה. נחשב לחשוד, עשוי להיות לגיטימי בהתאם לשימוש בארגון.
  • זליגת נתונים פוטנציאלית על ידי גורם פנימי מ-Chrome: זיהוי פעילות שקשורה להתנהגויות פוטנציאליות של איום פנימי, כולל זליגת נתונים או אובדן של מידע אישי רגיש פוטנציאלי מחוץ לארגון Google Workspace. זה כולל התנהגויות מ-Chrome שנחשבות חריגות בהשוואה לנתוני הבסיס של 30 יום.
  • זליגת נתונים פוטנציאלית על ידי גורם פנימי מ-Drive: זיהוי פעילות שקשורה להתנהגויות של איום פנימי פוטנציאלי, כולל זליגת נתונים או אובדן של מידע אישי רגיש פוטנציאלי מחוץ לארגון Google Workspace. זה כולל התנהגויות ב-Drive שנחשבות חריגות בהשוואה לנתוני הבסיס של 30 יום.
  • זליגת נתונים פוטנציאלית על ידי גורם פנימי מ-Gmail: זיהוי פעילות שקשורה להתנהגויות פוטנציאליות של איומים פנימיים, כולל זליגת נתונים או אובדן של מידע אישי רגיש פוטנציאלי מחוץ לארגון Google Workspace. ההתנהגויות האלה כוללות פעילות חריגה ב-Gmail בהשוואה לנתוני הבסיס של 30 יום.
  • פוטנציאל לפגיעה בחשבון Workspace: זיהוי התנהגויות של איומים פנימיים שמצביעות על כך שהחשבון עלול להיפגע, ועלולות להוביל לניסיונות להרחבת הרשאות או לניסיונות תנועה לרוחב בארגון Google Workspace. ההתנהגויות האלה נחשבות נדירות או חריגות בהשוואה לנתוני הבסיס של 30 ימים.
  • פעולות אדמיניסטרטיביות חשודות ב-Workspace: זיהוי התנהגויות שמצביעות על ניסיון התחמקות פוטנציאלי, על הורדת רמת האבטחה או על התנהגויות נדירות ואנומליות שלא נראו ב-30 הימים האחרונים אצל משתמשים עם הרשאות גבוהות יותר, כולל אדמינים.

מכשירים נתמכים וסוגי יומנים

בקטעים הבאים מפורטים הנתונים הנדרשים עבור קבוצות כללים בקטגוריה Cloud Threats (איומים ב-Cloud).

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

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

רשימה של כל מקורות הנתונים הנתמכים ב-Google SecOps זמינה במאמר בנושא מנתחי ברירת מחדל נתמכים.

כל קבוצות הכללים

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

קבוצת כללים של Cloud SQL Ransom

כדי להשתמש בקבוצת הכללים Cloud SQL Ransom, מומלץ לאסוף את הנתונים הבאים: Google Cloud

קבוצות כללים משופרות של סעיפים חוזיים סטנדרטיים (SCC) של CDIR

כל קבוצות הכללים שמתחילות בשם CDIR SCC Enhanced משתמשות בממצאים של Security Command Center Premium עם הקשר מכמה מקורות יומנים אחרים Google Cloud , כולל המקורות הבאים:

  • יומני ביקורת של Cloud
  • יומנים של Cloud DNS
  • ניתוח של ניהול זהויות והרשאות גישה (IAM)
  • הקשר של Sensitive Data Protection
  • הקשר של BigQuery
  • הקשר של Compute Engine

כדי להשתמש בערכות הכללים CDIR SCC Enhanced, מומלץ לאסוף את הנתונים הבאים: Google Cloud

  • נתוני היומן מפורטים בקטע כל קבוצות הכללים.

  • נתוני היומן הבאים, שמפורטים לפי שם המוצר ותווית ההטמעה של Google SecOps:

    • ‫BigQuery ‏ (GCP_BIGQUERY_CONTEXT)
    • ‫Compute Engine‏ (GCP_COMPUTE_CONTEXT)
    • IAM ‏ (GCP_IAM_CONTEXT)
    • ‫Sensitive Data Protection‏ (GCP_DLP_CONTEXT)
    • יומני ביקורת של Cloud (GCP_CLOUDAUDIT)
    • פעילות ב-Google Workspace ‏ (WORKSPACE_ACTIVITY)
    • שאילתות Cloud DNS‏ (GCP_DNS)

  • הסיווגים הבאים של ממצאים ב-Security Command Center, שמופיעים לפי מזהה findingClass ותווית ההטמעה של Google SecOps:

    • Threat (GCP_SECURITYCENTER_THREAT)
    • Misconfiguration (GCP_SECURITYCENTER_MISCONFIGURATION)
    • Vulnerability (GCP_SECURITYCENTER_VULNERABILITY)
    • SCC Error (GCP_SECURITYCENTER_ERROR)

ערכות הכללים של CDIR SCC Enhanced מסתמכות גם על נתונים משירותים Google Cloud . כדי לשלוח את הנתונים הנדרשים אל Google SecOps, צריך לוודא שביצעתם את הפעולות הבאות:

קבוצות הכללים הבאות יוצרות זיהוי כשמזוהות תוצאות מ-Security Command Center Event Threat Detection,‏ Google Cloud Armor,‏ Security Command Center Sensitive Actions Service ומודולים מותאמים אישית ל-Event Threat Detection:

  • CDIR SCC Cloud IDS
  • CDIR SCC Cloud Armor
  • ההשפעה של סעיפי החוזה הסטנדרטיים (SCC) של CDIR
  • שיפור העמידות של סעיפים חוזיים סטנדרטיים (SCC) ב-CDIR
  • CDIR SCC Enhanced Defense Evasion
  • מודול בהתאמה אישית של CDIR SCC

ערכת הכללים Kubernetes Suspicious Tools

כדי להשתמש בקבוצת הכללים Kubernetes Suspicious Tools, מומלץ לאסוף את הנתונים שמפורטים בקטע All rule sets. מוודאים שהשירותים מוגדרים להקלטת נתונים ביומני הצמתים של Google Kubernetes Engine ‏ (GKE) Google Cloud

קבוצת כללים לניצול לרעה של RBAC ב-Kubernetes

כדי להשתמש בקבוצת הכללים Kubernetes RBAC Abuse, מומלץ לאסוף יומני ביקורת ב-Cloud, שמופיעים בקטע All rule sets.

קבוצת כללים של פעולות רגישות בנושא אישורים של Kubernetes

כדי להשתמש בקבוצת הכללים Kubernetes Certificate Sensitive Actions, מומלץ לאסוף Cloud Audit Logs, שמופיעים בקטע All rule sets.

קבוצות כללים שקשורות ל-Google Workspace

קבוצות הכללים הבאות מזהות דפוסים בנתוני Google Workspace:

  • זליגת נתונים פוטנציאלית מ-Chrome על ידי משתמשים פנימיים
  • זליגת נתונים פוטנציאלית מ-Drive על ידי משתמשים פנימיים
  • זליגת נתונים פוטנציאלית מ-Gmail על ידי משתמשים פנימיים
  • פריצה פוטנציאלית לחשבון Workspace
  • פעולות אדמין חשודות ב-Workspace

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

  • פעילויות ב-Workspace (WORKSPACE_ACTIVITY)
  • התראות ב-Workspace ‏ (WORKSPACE_ALERTS)
  • מכשירי ChromeOS של Workspace ‏ (WORKSPACE_CHROMEOS)
  • מכשירים ניידים של Workspace (WORKSPACE_MOBILE)
  • משתמשי Workspace ‏ (WORKSPACE_USERS)
  • ממשק מרכזי לניהול דפדפן Chrome ‏ (CHROME_MANAGEMENT)
  • יומני Gmail‏ (GMAIL_LOGS)

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

קבוצת כללים של איומים בלי שרת (serverless)

יומני Cloud Run כוללים יומני בקשות ויומני קונטיינרים, שמוזנים כסוג היומן GCP_RUN ב-Google SecOps. אפשר להטמיע יומנים של GCP_RUN באמצעות הטמעה ישירה או באמצעות פידים ו-Cloud Storage. למידע נוסף על מסנני יומנים ספציפיים ועל פרטים נוספים לגבי הטמעה, אפשר לעיין במאמר בנושא ייצוא יומנים ל-Google SecOps. Google Cloud מסנן הייצוא הבא מייצא יומנים של Cloud Run ‏ (GCP_RUN), בנוסף ליומני ברירת המחדל, גם דרך מנגנון ההטמעה הישירה וגם דרך Cloud Storage ומאגרי מידע: Google Cloud 

log_id("run.googleapis.com/stdout") OR
log_id("run.googleapis.com/stderr") OR
log_id("run.googleapis.com/requests") OR
log_id("run.googleapis.com/varlog/system)

גלאים מוכנים מראש לקבוצות כללים של AWS

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

  • ‫AWS – Compute: זיהוי פעילות חריגה שקשורה למשאבי מחשוב ב-AWS, כולל EC2 ו-Lambda.
  • ‫AWS – נתונים: מזהה פעילות ב-AWS שמשויכת למשאבי נתונים, כולל תמונות מצב של RDS או קטגוריות S3 שהוגדרו כזמינות לציבור.
  • ‫AWS – GuardDuty: התראות מבוססות-הקשר של AWS GuardDuty לגבי התנהגות, גישה לפרטי כניסה, כריית מטבע וירטואלי, גילוי, התחמקות, הרצה, חילוץ, השפעה, גישה ראשונית, תוכנה זדונית, בדיקת חדירה, התמדה, מדיניות, הסלמת הרשאות (privilege escalation) וגישה לא מורשית.
  • ‫AWS – Hacktools: זיהוי השימוש ב-Hacktools בסביבת AWS, כמו סורקים, ערכות כלים ומסגרות.
  • ‫AWS – Identity: זיהויים של פעילות ב-AWS שמשויכת ל-IAM ולפעילות אימות, כולל כניסות לא רגילות ממספר מיקומים גיאוגרפיים, יצירת תפקידים עם הרשאות רחבות מדי או פעילות IAM מכלי חשודים.
  • ‫AWS – רישום ביומן ומעקב: זיהוי פעילות ב-AWS שקשורה להשבתה של שירותי רישום ביומן ומעקב, כולל CloudTrail,‏ CloudWatch ו-GuardDuty.
  • ‫AWS – רשת: זיהוי שינויים לא מאובטחים בהגדרות הרשת של AWS, כמו קבוצות אבטחה וחומות אש.
  • ‫AWS – Organization: זיהוי פעילות ב-AWS שמשויכת לארגון, כולל הוספה או הסרה של חשבונות ואירועים בלתי צפויים שקשורים לשימוש באזור.
  • ‫AWS - Secrets: מזהה פעילות ב-AWS שמשויכת לסודות, לאסימונים ולסיסמאות, כולל מחיקה של סודות ב-KMS או ב-Secrets Manager.

מכשירים נתמכים וסוגי יומנים ב-AWS

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

במאמר הגדרת הטמעה של נתונים מ-AWS מוסבר איך להגדיר הטמעה של נתונים מ-AWS.

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

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

אפשר להטמיע נתונים מ-AWS באמצעות קטגוריה של Amazon Simple Storage Service ‏ (Amazon S3) כמקור, או לחלופין באמצעות Amazon S3 עם Amazon Simple Queue Service ‏ (Amazon SQS). באופן כללי, תצטרכו לבצע את הפעולות הבאות:

  • מגדירים את Amazon S3 או את Amazon S3 עם Amazon SQS כדי לאסוף נתוני יומן.
  • הגדרת פיד של Google SecOps להעברת נתונים מ-Amazon S3 או מ-Amazon SQS

במאמר העברת יומנים של AWS אל Google SecOps מפורטים השלבים הנדרשים להגדרת שירותי AWS ולהגדרת פיד של Google SecOps להעברת נתונים של AWS.

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

במאמר אימות של הכנסת נתונים מ-AWS לקטגוריה Cloud Threats מוסבר איך לאמת את הכנסת הנתונים מ-AWS באמצעות כללי בדיקה של AWS Managed Detection Testing.

גלאים מוכנים מראש לנתוני Azure

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

  • ‫Azure – Compute: מזהה פעילות חריגה שקשורה למשאבי מחשוב של Azure, כולל Kubernetes ומכונות וירטואליות (VM).
  • ‫Azure – נתונים: זיהוי פעילות שמשויכת למשאבי נתונים, כולל הרשאות, שינויים והזמנות של Azure blob למשתמשים חיצוניים לשימוש בשירותי Azure בדייר.
  • ‫Azure – Defender for Cloud: מזהה התראות שהתקבלו מ-Microsoft Defender for Cloud שמודע להקשר, שקשורות להתנהגות משתמשים, לגישה לפרטי כניסה, לכריית מטבעות קריפטוגרפיים, לגילוי, להתחמקות, להרצה, להעברה לא מורשית, להשפעה, לגישה ראשונית, לתוכנות זדוניות, לבדיקות חדירה, להתמדה, למדיניות, להרחבת הרשאות או לגישה לא מורשית בכל שירותי הענן של Azure.
  • ‫Azure - Hacktools: זיהוי שימוש בכלי פריצה בסביבת Azure, כולל Tor, כלי VPN לאנונימיזציה, סורקים וערכות כלים של צוותים אדומים.
  • ‫Azure – Identity: זיהוי פעילות שקשורה לאימות ולהרשאה, שמעידה על התנהגות חריגה, כולל גישה בו-זמנית מכמה מיקומים גיאוגרפיים, מדיניות ניהול גישה מתירנית מדי או פעילות של Azure RBAC מכלי חשוד.
  • ‫Azure - Logging and Monitoring: זיהוי פעילות שקשורה להשבתה של שירותי רישום ביומן ומעקב ב-Azure.
  • ‫Azure – Network: זיהוי שינויים לא מאובטחים ובולטים בהגדרות או במכשירים של Azure networking, כולל קבוצות אבטחה או חומות אש, חומת אש ליישומי אינטרנט (WAF) של Azure ומדיניות בנושא התקפת מניעת שירות (DoS).
  • ‫Azure – Organization: מזהה פעילות שמשויכת לארגון שלכם, כולל הוספה או הסרה של מינויים וחשבונות.
  • ‫Azure – Secrets: זיהוי פעילות שמשויכת לסודות, לטוקנים ולסיסמאות (לדוגמה, שינויים ב-Azure Key Vault או במפתחות גישה לחשבון אחסון).

מכשירים נתמכים וסוגי יומנים נדרשים ל-Azure

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

הוספת נתונים מ-Azure ומ-Microsoft Entra ID

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

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

אימות ההטמעה של נתוני Azure

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

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

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

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

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

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

  1. ב-Azure, יוצרים משתמש חדש ב-Microsoft Entra ID.

    1. עוברים אל Azure Portal.
    2. פותחים את Microsoft Entra ID.
    3. לוחצים על הוספה ואז על יצירת משתמש חדש. כדי להגדיר את המשתמש, מבצעים את הפעולות הבאות:
      1. מזינים את הפרטים הבאים:
        • שם המשתמש הראשי: GCTI_ALERT_VALIDATION
        • שם המשתמש הראשי: GCTI_ALERT_VALIDATION
        • השם המוצג: GCTI_ALERT_VALIDATION
      2. בוחרים באפשרות יצירת סיסמה באופן אוטומטי כדי ליצור סיסמה למשתמש באופן אוטומטי.
      3. מסמנים את תיבת הסימון החשבון מופעל.
      4. פותחים את הכרטיסייה בדיקה + יצירה.
      5. חשוב לזכור את הסיסמה שנוצרה אוטומטית. תשתמשו בזה בשלבים הבאים.
      6. לוחצים על יצירה.
    4. פותחים חלון דפדפן במצב פרטי ועוברים לפורטל Azure.
    5. נכנסים לחשבון באמצעות המשתמש והסיסמה החדשים.
    6. משנים את סיסמת המשתמש.
    7. מגדירים אימות רב-שלבי (MFA), כפי שנדרש בארגון.
    8. יוצאים מפורטל Azure ומאשרים את היציאה.

  2. כדי לוודא שההתראות נוצרות ב-Google Security Operations:

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

    2. לוחצים על מרכז בקרה.

    3. ברשימת הזיהויים, בודקים שהכללים הבאים הופעלו:

      • tst_azure_ad_user_creation
      • tst_azure_ad_user_login

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

שליחת התראות לדוגמה להפעלת כללי הבדיקה

כדי לוודא שיצירת התראות אבטחה לדוגמה ב-Azure מפעילה את כללי הבדיקה, מבצעים את השלבים הבאים. מידע נוסף על יצירת התראות אבטחה לדוגמה ב-Microsoft Defender for Cloud זמין במאמר אימות התראות ב-Microsoft Defender for Cloud.

  1. ב-Azure Portal, עוברים אל All Services (כל השירותים).
  2. בקטע Security (אבטחה), פותחים את Microsoft Defender for Cloud.
  3. עוברים אל התראות אבטחה.
  4. לוחצים על Sample Alerts (התראות לדוגמה) ומבצעים את הפעולות הבאות:
    1. בוחרים את המינוי.
    2. בוחרים באפשרות all בשדה Defender for Cloud Plans.
    3. לוחצים על יצירת התראות לדוגמה.
  5. מוודאים שהתראות הבדיקה מופעלות.
  6. ב-Google Security Operations, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו).
  7. לוחצים על מרכז בקרה.
  8. ברשימת הזיהויים, מוודאים שהופעלו הכללים הבאים:
    • tst_azure_activity
    • tst_azure_defender_for_cloud_alerts

הפעלת בקשת GET API ב-Microsoft Graph Explorer כדי להפעיל את כללי הבדיקה

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

  1. עוברים אל Microsoft Graph Explorer.
  2. מוודאים שהדייר המתאים נבחר.
  3. לוחצים על Run Query (הפעלת שאילתה).
  4. מוודאים שהתראות הבדיקה מופעלות.
  5. ב-Google Security Operations, לוחצים על Detections (זיהויים) > Rules & Detections (כללים וזיהויים) כדי לפתוח את הדף Curated Detections (זיהויים שנאספו).
  6. לוחצים על מרכז בקרה.
  7. ברשימת הזיהויים, בודקים שהופעל הכלל tst_microsoft_graph_api_get_activity.

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

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

גלאים מוכנים מראש לנתוני Office 365

ערכות הכללים של Office 365 בקטגוריה הזו עוזרות לזהות איומים בסביבות של Office 365 באמצעות נתונים של אירועים והקשרים, והן כוללות את ערכות הכללים הבאות:

  • ‫Office 365 – אדמיניסטרטיבי: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Office 365, כולל שינויים במדיניות הגיבוי, ב-Microsoft Purview ובזיהויים של ATP.

  • ‫Office 365 – eDiscovery: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Office 365 eDiscovery, כולל ניסיונות חיפוש של פרטי כניסה או מידע אישי רגיש אחר.

  • ‫Office 365 – אימייל: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה באימייל של Office 365, כולל ניסיונות פישינג, שינויים מסוכנים בהגדרות האימייל ופעילות חשודה באימייל.

  • ‫Office 365 – Forms: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Office 365 Forms, כולל ניסיונות פישינג ועדכוני סטטוס לגבי חשבונות ב-Forms.

  • ‫Office 365 – Identity: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Office 365 שקשורות לניהול זהויות והרשאות גישה, כולל גניבת טוקנים פוטנציאלית, הגדרות אימות מסוכנות, מתקפות על אימות רב-גורמי (MFA), מתקפות על סיסמאות וכלי פריצה ידועים.

  • ‫Office 365 – Sharepoint ו-OneDrive: מזהה פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Sharepoint וב-OneDrive של Office 365, כולל העלאות של תוכנות זדוניות, שיתוף קבצים אנונימי וחיפושים של פרטי כניסה ונתונים פיננסיים.

  • ‫Office 365 – Teams: זיהוי פעילויות זדוניות, חשודות ובעלות סיכון גבוה ב-Office 365 Teams, כולל התחזות לחשבונות Teams, ייצוא של הקלטות ותמלילים.

מכשירים נתמכים וסוגי יומנים שנדרשים ל-Office 365

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

זיהוי מותאם אישית של קבוצות כללים ב-Okta

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

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

מכשירים נתמכים וסוגי יומנים שנדרשים ל-Okta

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

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

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

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

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

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