איומים בענן

נתמך ב:

במאמר הזה מפורטת סקירה כללית של קבוצות הכללים בקטגוריה 'איומים ב-Cloud', מקורות הנתונים הנדרשים וההגדרות שבהן אפשר להשתמש כדי לכוונן את ההתראות שנוצרות על ידי כל קבוצת כללים. ערכות הכללים האלה עוזרות לזהות איומים בסביבות 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: מכיל כללים שמתחשבים בהקשר ומבצעים קורלציה בין תוצאות של Security Command Center Credential Access לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני הביקורת של Cloud
  • ‫CDIR SCC Enhanced Discovery: מכיל כללים מודעים-הקשר שמתאימים בין ממצאי הסלמה של Discovery ב-Security Command Center לבין נתונים ממקורות כמו Google Cloud שירותים ויומני ביקורת של Cloud.
  • ‫CDIR SCC Brute Force: מכיל כללים מודעי-הקשר שיוצרים קורלציה בין ממצאי הסלמה של Brute Force ב-Security Command Center לבין נתונים, כולל יומנים של Cloud DNS.
  • ‫CDIR SCC Data Destruction: מכיל כללים שמתחשבים בהקשר ומשווים בין ממצאי הסלמה של 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 Initial Access לבין נתונים מכמה מקורות נתונים אחרים, כולל יומני הביקורת של Cloud.
  • ‫CDIR SCC Impair Defenses: מכיל כללים מודעים-הקשר שמתאמים בין תוצאות של Security Command Center בנושא פגיעה בהגנות לבין נתונים ממספר מקורות נתונים אחרים, כולל יומני ביקורת של Cloud.
  • ‫CDIR SCC Impact: מכיל כללים שמזהים ממצאים של Impact מ-Security Command Center עם סיווג של מידת חומרה קריטית, גבוהה, בינונית ונמוכה.
  • ‫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: Detects activity associated with potential exfiltration of data.
  • התחזות למשאב: זיהוי 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.

כדי להטמיע נתונים מ 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 ו-Custom modules for Event Threat Detection:

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

קבוצת הכללים Kubernetes Suspicious Tools

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

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

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

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

כדי להשתמש בקבוצת הכללים Kubernetes Certificate Sensitive Actions, מומלץ לאסוף יומני ביקורת של Cloud, שמופיעים בקטע 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 Threats

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

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 – זהות: זיהויים של פעילות ב-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 – ארגון: מזהה פעילות שמשויכת לארגון, כולל הוספה או הסרה של מינויים וחשבונות.
  • ‫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.
    2. פותחים את Microsoft Entra ID.
    3. לוחצים על Add ואז על Create New User. כדי להגדיר את המשתמש:
      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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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