מדריך

דרישות מחמירות לריבונות נתונים באזורים גיאוגרפיים מרובים.

→פרוס סביבות עבודה מרובות של Microsoft Sentinel, אחת לכל אזור. השתמש ב-Azure Lighthouse לניהול מרכזי.

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

מקור↗

סביבת עבודה של Sentinel קולטת למעלה מ-100 GB של נתונים ביום.

→שנה את רמת התמחור של סביבת העבודה של Log Analytics מ-Pay-As-You-Go ל-Commitment Tiers.

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

יומנים בנפח גבוה (לדוגמה, אירועי אבטחה של Windows) מעלים את עלויות ה-SIEM.

→1. השתמש ב-Data Collection Rule (DCR) כדי לסנן אירועים במקור. 2. הגדר את טבלת היעד עבור Basic Logs.

למה: DCRs מפחיתים את עלויות הקליטה על ידי איסוף אירועים הכרחיים בלבד. Basic Logs מפחיתים את עלויות האחסון עבור נתונים מפורטים שאינם דורשים ניתוח מלא.

מקור↗

תאימות דורשת שמירת נתונים למשך יותר משנתיים (לדוגמה, 7 שנים).

→הגדר את סביבת העבודה עם שמירה אינטראקטיבית למשך 90 יום ושמירה כוללת למשך 7 שנים (שכבת ארכיון).

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

אסוף אירועי אבטחה משרתי Windows ו-Linux מקומיים.

→התקן את סוכן Azure Arc לניהול, ולאחר מכן פרוס את Azure Monitor Agent (AMA) דרך Arc.

למה: Arc מרחיב את מישור הבקרה של Azure למערכות מקומיות, ומאפשר ניהול מקורי ואיסוף נתונים באמצעות סוכן ה-AMA המודרני.

קלוט יומנים מהתקני צד שלישי (לדוגמה, חומות אש) התומכים ב-Syslog.

→פרוס מכונה וירטואלית ייעודית של Linux כ-Log Forwarder עם ה-AMA. השתמש בפורמט CEF עבור נתוני אבטחה מובנים.

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

קלוט אירועים והתראות מ-Microsoft Defender XDR לתוך Sentinel.

→הפעל את מחבר הנתונים של Microsoft Defender XDR ואת אפשרות יצירת האירועים/סנכרון דו-כיווני שלו.

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

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

→הגדר Data Collection Rule (DCR) עם שאילתת XPath כדי לציין אילו מזהי אירועים לאסוף.

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

דורש את זמן הזיהוי המהיר ביותר האפשרי עבור אירועים קריטיים.

→השתמש בכלל ניתוח בקירוב לזמן אמת (NRT).

למה: כללי NRT פועלים בכל דקה, ומציעים זמן אחזור זיהוי של כ-1-2 דקות, מהיר בהרבה מהמינימום של 5 דקות עבור כללים מתוזמנים.

זיהוי סף אירועים בתוך חלון זמן ספציפי (לדוגמה, התקפות כוח גס).

→צור כלל ניתוח מתוזמן באמצעות KQL `summarize ... by bin(TimeGenerated, 5m), ...`.

למה: הפונקציה `bin()` חיונית לקיבוץ אירועים לחלונות זמן נפרדים ולא חופפים, לצורך זיהוי סף מדויק.

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

→הפעל כללי ניתוח Fusion לזיהוי מתקפות רב-שלביות מתקדמות.

למה: Fusion משתמש ב-ML כדי לתאם אותות בעלי מהימנות נמוכה על פני מקורות נתונים מרובים לאירועים בעלי מהימנות גבוהה, ובכך מפחית את עומס ההתראות.

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

→הפעל ניתוח התנהגות משתמשים וייויות (UEBA).

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

כתוב כלל ניתוח יחיד, בלתי תלוי במקור, עבור מקורות נתונים מרובים (לדוגמה, DNS מספקים שונים).

→השתמש במנתחי Advanced Security Information Model (ASIM) בשאילתת ה-KQL.

למה: ASIM מספק סכימה מנורמלת, המאפשרת להריץ שאילתות כנגד תצוגה מאוחדת (לדוגמה, `imDns`) במקום כנגד טבלאות מרובות ספציפיות לספק.

נהל תוכן של Sentinel (כללי ניתוח, חוברות עבודה) כקוד ופרוס אותו על פני סביבות.

→השתמש במאגרי Microsoft Sentinel לחיבור מאגר GitHub או Azure DevOps.

למה: מאפשר זרימות עבודה של CI/CD, בקרת גרסאות ופריסה אוטומטית ועקבית של תוכן אבטחה (Sentinel-as-Code).

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

→השתמש בכלל אוטומציה המופעל בעת יצירת אירוע.

למה: כללי אוטומציה קלי משקל וסינכרוניים, אידיאליים לפעולות תעדוף פשוטות ללא העלות התקורה של Logic App.

הפוך לממוכנות תגובות מורכבות לאירועים הכוללות מערכות חיצוניות (לדוגמה, חסימת משתמש ב-Entra ID, שליחת הודעת Teams).

→צור Playbook (Azure Logic App) והפעל אותו מכלל אוטומציה.

למה: Logic Apps מספקות את מנוע התזמור ואת המחברים הדרושים לתגובות ושילובים מורכבים ורב-שלביים.

הבן את היקף התקפה באמצעות הדמיית קשרים בין יישויות (משתמשים, כתובות IP, מארחים).

→השתמש בגרף החקירה (Investigation Graph) בדף פרטי האירוע.

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

תקנן והאץ זרימות עבודה נפוצות של חקירות עבור צוות ה-SOC.

→צור ושתף Promptbook ב-Microsoft Security Copilot.

למה: Promptbooks מחברים יחד סדרת הנחיות בשפה טבעית ליצירת תהליך חקירה מודרך וניתן לחזרה עבור תרחישים נפוצים.

נהל הרשאות אבטחה באופן מרכזי עבור כל מוצרי Microsoft Defender.

→הפעל את מודל ה-RBAC המאוחד של Microsoft Defender XDR.

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

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

→הגדר את הגדרות החקירה האוטומטית עבור קבוצות מכשירים, הגדר את רמת האוטומציה ל-'Full' או 'Semi'.

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

מקור↗

חסום מידית גיבוב קובץ, כתובת IP או כתובת URL זדוניים ידועים בכל נקודות הקצה.

→צור Indicator of Compromise (IoC) עם פעולת "חסימה ותיקון".

למה: מספק מנגנון הכלה מהיר, כלל-ארגוני, שהוא מהיר יותר מלהמתין לעדכוני חתימות AV.

חזק את נקודות הקצה על ידי חסימת טכניקות תקיפה נפוצות (לדוגמה, Office היוצר תהליכי ילד).

→פרוס כללי Attack Surface Reduction (ASR), החל במצב 'Audit' כדי להעריך את ההשפעה לפני המעבר ל-'Block'.

למה: כללי ASR הם בקרת מניעה מרכזית. מצב Audit חיוני למניעת שיבושים ביישומי עסקים במהלך ההטמעה.

בצע חקירה פורנזית מעמיקה או תיקון ידני בנקודת קצה פעילה.

→השתמש בתכונת Live Response כדי ליצור מעטפת מרוחקת ולאסוף חבילות פורנזיות.

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

שחזר פעולות של תוקף במכשיר ספציפי שנפרץ.

→נתח את ציר הזמן של המכשיר (Device Timeline).

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

זיהוי גניבת אישורים וטכניקות תנועה רוחבית כמו Pass-the-Hash/Ticket.

→פרוס חיישני Microsoft Defender for Identity על כל בקרי התחום (Domain Controllers).

למה: Defender for Identity מנטר ישירות תעבורת אימות AD מקומית, ומספק התראות בעלות מהימנות גבוהה עבור התקפות מבוססות זהות.

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

→הגדר מדיניות קבצים מצורפים בטוחים (Safe Attachments) עם אפשרות Dynamic Delivery.

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

מצא והסר את כל המופעים של דוא"ל דיוג מתיבות דוא"ל של משתמשים.

→השתמש ב-Threat Explorer (או Advanced Hunting) כדי לחפש את הדוא"ל ולבצע פעולת מחיקה רכה או קשה.

למה: Threat Explorer הוא כלי חיפוש ותיקון רב עוצמה לטיהור איומים פעילים ממערכת הדוא"ל בכל הארגון.

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

→הגדר מדיניות סשן של Defender for Cloud Apps באמצעות Conditional Access App Control.

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

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

→הפעל את Automatic Attack Disruption ב-Microsoft Defender XDR.

למה: משתמש באותות חוצי-תחומים (XDR) כדי לנקוט בפעולה נחרצת במהירות מכונה, כגון השבתת חשבונות משתמשים שנפרצו ובידוד מכשירים.

חיפוש יזום של איומים בכל נתוני XDR (נקודת קצה, דוא"ל, זהות, אפליקציות ענן).

→השתמש ב-Advanced Hunting עם Kusto Query Language (KQL).

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

הבנה מהירה של ההיקף המלא של אירוע מורכב הכולל התראות וישויות מרובות.

→נתח את Attack Story או Investigation Graph של האירוע.

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

הרחב את הגנות עומסי העבודה של Defender for Cloud לשרתים מקומיים ולשרתים מרובי עננים.

→צרף את השרתים באמצעות Azure Arc, ולאחר מכן הפעל את תוכנית Defender for Servers.

למה: Azure Arc פועל כגשר מישור בקרה, ומקרין משאבים שאינם Azure לתוך Azure כך שניתן יהיה לנהל ולאבטח אותם על ידי Defender for Cloud.

הבן במהירות את מטרתו ואת הפוטנציאל הזדוני של סקריפט מורכב (לדוגמה, PowerShell).

→הדבק את הסקריפט לתוך Security Copilot ובקש ניתוח של תפקודיו וסיכוניו.

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

הכלה מיידית של חשבון משתמש שנפרץ ומסונכרן מ-AD מקומי.

→השבת את החשבון ב-Active Directory המקומי, ולאחר מכן הפעל סנכרון AD Connect מיידי.

למה: עבור זהויות מסונכרנות, ה-AD המקומי הוא מקור הסמכות. השבתת החשבון שם היא פעולת ההכלה היעילה ביותר.

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

→השתמש במחבר הנתונים 'Threat Intelligence - TAXII' ב-Sentinel.

למה: מתחבר לשרתי TAXII 2.x כדי לייבא באופן אוטומטי אינדיקטורים בפורמט STIX, ומאפשר תפעול של מידע מודיעיני אודות איומים.

מקור↗

תאם אינדיקטורי איומים ידועים (כתובות IP, דומיינים, גיבובים) מול כל מקורות היומן שנקלטו.

→קלוט אינדיקטורים לטבלת ThreatIntelligenceIndicator והפעל את כללי הניתוח המובנים "TI map...".

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

השתמש ברשימה מותאמת אישית של אינדיקטורים (לדוגמה, כתובות IP של שותפים עסקיים, חשבונות עובדים מפוטרים) להתראה או העשרה.

→צור Watchlist וצרף אותו עם נתונים בשאילתות KQL.

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

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

→1. שמור את השאילתה בלהב הציד (Hunting blade). 2. קדם את שאילתת הציד לכלל ניתוח מתוזמן.

למה: ממסד את המעבר מגילוי אד-הוק (ציד) לזיהוי אוטומטי וניתן לחזרה (כלל ניתוח).

הערך את כיסוי הזיהוי וזהה פערים בהתבסס על מסגרת MITRE ATT&CK.

→השתמש בלהב MITRE ATT&CK ב-Sentinel. תייג כללי ניתוח בטקטיקות/טכניקות רלוונטיות.

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

שמור תוצאות מעניינות או ראיות שנמצאו במהלך ציד לצורך מעקב עתידי.

→צור סימניית ציד (Hunting Bookmark) מתוצאות שאילתת KQL.

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