- Zen IT Technologies
- מוכנות ותגובה לאירועי אבטחה
היכולת שלכם להגיב לאירוע נבנית הרבה לפני שתצטרכו אותה.
תגובה לאירועי אבטחה היא לא משהו שמוסיפים אחרי שמשהו כבר קרה. אנחנו בונים את היכולת הזו כחלק מסביבת ה-IT שאנחנו מנהלים: טלמטריית אבטחה ומדיניות השמירה שמאחוריה, יכולות זיהוי שמתוחזקות מול דפוסי תקיפה עדכניים, ראיות שאפשר לאסוף בלי להגיע פיזית למכשיר, והמלאי והגישה שנדרשים כדי לקבוע היקף של אירוע על פני זהויות, תחנות קצה, רשת ושירותי SaaS.
כשמתפרסם Indicator of Compromise חדש, מתגלה פגיעה בחבילה, בספרייה או ברכיב אחר, או עולה חשד לאירוע אבטחה, הסביבה כבר בנויה כדי לענות על השאלות שקובעות את התוצאה: מה הושפע, מה קרה, מה צריך לבודד ואיך חוזרים לפעילות תקינה.
הבעיה
רוב הארגונים מגלים מה יכולת התגובה שלהם בזמן האירוע עצמו.
ההתראה מתקבלת והשאלות מתחילות מיד. איזה מחשב. איזה משתמש. לאילו מערכות או נתונים הייתה גישה. האם אותם פרטי גישה שימשו במקום נוסף. ומתחת לכולן, השאלה שבאמת קובעת את התוצאה: האם בכלל אפשר לברר?
הפערים חוזרים על עצמם, ותמיד מתגלים מאוחר מדי:
-
אין כלי פורנזיקה מותקנים.
איסוף הראיות תלוי בגישה פיזית למכשיר שעשוי להיות במדינה אחרת.
-
הלוגים כבר לא זמינים.
יומני ביקורת חשובים עלולים כבר לא להיות זמינים עד שמבינים את מלוא היקף האירוע.
-
אין מלאי שאפשר להישען עליו.
אף אחד לא יודע לומר אילו שירותי SaaS מחזיקים מידע ארגוני, או אילו service accounts קיימים.
-
אין הסכמה על סמכויות החלטה.
רק תוך כדי האירוע מתחילים לברר מי מוסמך לאשר הורדה של מערכת ייצור באמצע הלילה.
-
שום דבר לא נכתב בסוף.
האירוע נסגר, וחצי שנה אחר כך לקוח, מבקר או חברת ביטוח שואלים מה קרה.
מה כוללת מוכנות לתגובה לאירועי אבטחה
- זהויות
- תחנות קצה
- רשת
- SaaS וענן
-
יכולת תגובה שנבנית לתוך הסביבה
מוכנות לאירועים היא חלק מניהול תקין של סביבה ולא מוצר נפרד. בפועל מדובר בדרישות שמוטלות על מערכות שכבר קיימות: כלי איסוף ראיות שמגיעים לכל מכשיר מנוהל דרך פלטפורמת ניהול תחנות הקצה, כך שאיסוף הראיות לא מתחיל בהגעה פיזית למכשיר שעשוי להיות במדינה אחרת; שמירת יומני ביקורת שנקבעת מול משכי חקירה ריאליים ולא לפי ברירת המחדל של הפלטפורמה; יכולות זיהוי שמתוחזקות מול דפוסי תקיפה עדכניים; ומלאי נכסים וזהויות מעודכן מספיק כדי לקבוע לפיו היקף.
אנחנו קובעים מה חייב להיות ניתן לאיסוף ומוודאים שזה אכן כך. פלטפורמות הזהויות, תחנות הקצה והרשת נשארות מישורי הבקרה שעליהם הדרישות האלה ממומשות, ולכן המוכנות נשמרת ככל שהסביבה משתנה במקום להיבנות מחדש בכל אירוע.
-
מתחילים מקו בסיס ברור
אנחנו מתחילים בבדיקה של מה באמת אפשר לזהות, לחקור ולשחזר כבר היום: כיסוי הכלים, שמירת הלוגים, שלמות המלאי, החשיפה במערך הזהויות, יכולות ההתאוששות וסמכויות ההחלטה.
ההבחנה שחשובה כאן היא בין הגדרה שמופעלת לבין ראיה שאפשר באמת לשלוף, ולכן היכן שזה מעשי אנחנו מוודאים את הנתיב במקום להסתפק בתצורה. מדיניות שמירה שאף אחד מעולם לא שלף ממנה דבר היא מדיניות, לא יכולת. הפערים נכנסים לתוכנית העבודה, ואת רובם אפשר לסגור עם יכולות שכבר נמצאות בבעלות הארגון וברישוי שלו ולא עם פלטפורמה נוספת. התוכנית מתוחזקת ככל שהסביבה משתנה.
-
ניטור, התראות וטלמטריה
נתיב אותות האבטחה הוא דבר שצריך לתכנן ולתחזק: אילו מקורות נאספים, לאן הם מגיעים, כמה זמן הם נשמרים, ומה מותר לו להרים התראה. הצורה הנכונה לזה אינה זהה בכל חברה.
רוב הסביבות כבר מייצרות יותר אותות ממה שמישהו משתמש בהם, ולכן הצעד הראשון הוא בדרך כלל לגרום לפלטפורמות הזהויות ותחנות הקצה שכבר קיימות לעשות את מה שהן יודעות: אירועי התחברות וסיכון שהופכים למספר קטן של התראות שמישהו באמת יקרא, אותות סיכון זהות שמזינים את מדיניות הגישה המותנית שמערך הזהויות מחזיק, ותגובה אוטומטית במצבים שברורים מספיק כדי להצדיק אותה. ריכוז טלמטריה, קורלציה על פני חלונות זמן ארוכים יותר ומערכי SIEM נבנים היכן שהסביבה מצדיקה אותם.
זמינות המקורות עצמם היא חלק מהעבודה כאן, כי מקור שהפסיק לדווח בשקט נראה בדיוק כמו מקור שאין לו מה לדווח. ניטור הזמינות של האפליקציות והתשתית הוא חלק מתפעול הרשת ותחנות הקצה. מה ששייך לכאן הוא השאלה אם האירועים שחשובים נאספים, נשמרים ומורגשים, וזו שאלה אחרת מהשאלה אם מישהו צופה במסך מסביב לשעון.
-
תכנון תגובה
נהלי תפעול לתרחישים שבאמת קורים: פריצה לתחנת קצה, השתלטות על פרטי גישה ועל sessions, ופגיעה בתלות חיצונית. לכל אחד רצף בלימה ששומר על הראיות במקום להשמיד אותן. סמכויות החלטה, מסלולי הסלמה ואחריות על תקשורת, שמוסכמים בזמן שכולם רגועים. נוהל נכתב מול הכלים והנתיבים שקיימים בסביבה בפועל, ולכן התכנון בא אחרי התיקון ולא לפניו: תוכנית שמניחה נתיב איסוף שאף אחד לא בנה נכשלת כבר בצעד הראשון.
-
בדיקה ופעולה בכלל הסביבה
כשמתפרסם Indicator of Compromise חדש, או מתגלה שחבילה או ספרייה חיצונית נפרצו, השאלות פשוטות: באילו מכשירים זה נמצא, האם יש בידינו הלוגים שיראו את זה, אפשר לשאול אותם, ואפשר להריץ בדיקה על פני כל הסביבה.
התשובה מורכבת מארבע מערכות שונות ואף אחת מהן לא מספיקה לבדה: טלמטריית תחנות הקצה והיכולת לשאול את כל הצי מגיעות מפלטפורמת הניהול; הקשר ההתחברות, מצב ה-sessions והיסטוריית הגישה מגיעים ממערך הזהויות; היסטוריית הפעולות והניהול מגיעה מיומני הביקורת של שירותי ה-SaaS והענן; טלמטריית הרשת מגיעה מהקצה.
אנחנו קובעים מה צריך לשאול, קוראים את התשובות יחד, ומתאמים את הפעולה שנדרשת דרך הפלטפורמה שאחראית עליה. היכולת אינה נמצאת באף אחת מהקונסולות האלה בנפרד, אלא ביכולת להניח את התשובות שלהן זו לצד זו בזמן שהאירוע עדיין פתוח.
-
תגובה לאירועי אבטחה וחקירה דיגיטלית
כשמשהו קורה בזמן אמת, הדבר הראשון הוא טריאז׳: לקבוע מה זה בעצם, עד לאן זה מגיע, ומה חייב לקרות בשעה הקרובה. ההיקף נקבע מתוך הראיות ולא מונח מתוך ההתראה: איסוף וניתוח מתחנות הקצה, איסוף יומני ביקורת מ-Google Workspace, מ-Microsoft 365 וממערכות ניהול קוד, וכל מה שאפשר להוציא מהסביבה בנוגע לשימוש חוזר בפרטי גישה ולתנועה רוחבית. הבלימה מתואמת מול מי שמחזיק כל מישור בקרה, כדי שמה שעוצר את התוקף לא ימחק גם את התיעוד.
בסוף נכתב דוח: ציר זמן, נתיב כניסה, היקף, פעולות בלימה, גורם שורש וסטטוס תיקונים, בצורה שעומדת בקריאה של לקוח, מבקר או חברת ביטוח. אחרי התיקונים עוקבים עד לסגירה, ומה שהאירוע לימד על הזיהוי חוזר לתוך הזיהוי.
-
התאוששות אחרי אירוע אבטחה
התגובה לא מסתיימת בבלימה. לפני שמשחזרים משהו אנחנו קובעים מה חייב להישמר, כי שחזור שנעשה מוקדם מדי משמיד בדיוק את הראיות שהיו מסבירות את האירוע.
סדר החזרה לפעילות נגזר מהבלימה ולא מהלחץ: מערכות חוזרות אחרי שנתיב הגישה נסגר והתיקון אומת, ולא אחרי שהגיבוי הסתיים. גיבויים, בדיקות שחזור ותכנון המשכיות עסקית הם חלק מניהול הסביבה הרחבה. מה ששייך לכאן הוא שיקול הדעת האבטחתי שמופעל עליהם: מה לשמר, מתי בטוח לשחזר, ואיך קובעים שמה שחזר נקי.
מסמכים טכניים באנגלית
צורת הגל מזהה את מקורו מהר יותר מניתוח הקובץ עצמו.
עוד בנושא
איך זה עובד
-
בחינה.
סקירה מתועדת של יכולת התגובה הנוכחית שלכם, עם דירוג הפערים לפי הנזק והעיכוב שכל אחד מהם עלול לגרום בזמן אירוע.
-
תיקון.
סגירת הפערים על הפלטפורמות שכבר מנהלות את הסביבה: כלי איסוף ראיות שמגיעים לכל הצי, שמירת לוגים שמוארכת היכן שברירת המחדל הייתה נגמרת באמצע חקירה, מלאי שמושלם עד לרמה שאפשר לקבוע לפיו היקף, ויכולות זיהוי שנכתבות מול התקיפות הרלוונטיות לכם.
-
תכנון.
נהלי תפעול לתרחישים הרלוונטיים, וסמכויות החלטה שנקבעות מראש: מי מוסמך לאשר הורדה של מערכת ייצור, ומי מחליט כשאי אפשר להשיג אותו.
-
תחזוקה.
התוכנית נבדקת מחדש ככל שהסביבה ודפוסי התקיפה משתנים. תוכנית שנכתבה פעם אחת היא תוכנית שתהיה שגויה.
זה לא שירות חירום שמזמינים רק כשמשהו משתבש. המוכנות נשמרת כחלק מהשירות השוטף, כך שכאשר מתרחש אירוע אנחנו פועלים מתוך סביבה שאנחנו כבר מכירים ומנהלים.
דוגמאות מהשטח
-
יכולת פורנזית שהוטמעה לפני שנדרשה.
חברת טכנולוגיה
כלי איסוף ראיות הופצו על פני כל הצי דרך פלטפורמת הניהול הקיימת, כך שאיסוף מרחוק הוא הנתיב הרגיל ולא משהו שמסדרים תוך כדי האירוע, כולל עבור עובדים וקבלנים שעובדים ממדינה אחרת. כשהמכשיר מחובר ומנוהל, החקירה מתחילה באיסוף הראיות במקום בהטמעת הכלים שיאספו אותן.
-
שמירת יומני ביקורת הוארכה מעבר לברירות המחדל.
פלטפורמת SaaS
חלונות השמירה בפלטפורמות הזהויות, שיתוף הפעולה וניהול הקוד נבחנו מול משכי חקירה ריאליים, והוארכו במקומות שבהם ברירת המחדל לא הייתה מספיקה לאורך חקירה מלאה. דרכי האיסוף תועדו לצדם.
-
יכולות זיהוי נבנו מחדש תוך כדי קמפיין תקיפה פעיל.
חברת טכנולוגיה
Indicators of Compromise שזוהו במסגרת קמפיין פעיל בשרשרת האספקה הוטמעו כיכולות זיהוי על פני כל צי המכשירים עוד באותו יום. כלי איסוף ראיות נפרסו בכל הסביבה, והחקירה אפשרה לקבוע באופן חד-משמעי את היקף החשיפה ולתעד את הממצאים בדוח מסכם פורמלי.
-
תקלה רוחבית ב-EDR נבלמה ונפתרה מול הספק.
חברת טכנולוגיה
עדכון של מערכת ההפעלה הכניס את פלטפורמת תחנות הקצה ללולאת זיהוי על פני כל הצי, כשהיא מסמנת רכיבים של מערכת ההפעלה עצמה. בוצע תחקור על פני כל הצי, נבנתה מדיניות חריגים מתוכננת במקום טיפול לפי כל התראה בנפרד, והתקלה הוסלמה לספק ולוותה עד לגרסה מתוקנת.
לפי בקשה, ניתן לתאם שיחה פרטית עם לקוחות או ממליצים, בכפוף להסכמתם מראש. דוגמאות הלקוחות כאן אנונימיות במכוון.
למי זה מתאים
לחברות שמעדיפות לגלות מה הן יכולות לחקור עכשיו, ולא בזמן אירוע. בדרך כלל לקראת ביקורת, אחרי אירוע שכמעט קרה, או כששאלון אבטחה של לקוח שואל שאלה שאף אחד לא יודע לענות עליה.
בדרך כלל המערכות כבר נמצאות שם. הזהויות, תחנות הקצה, שירותי ה-SaaS והרשת מייצרים כל אחד משהו שימושי, והפער הוא שאף אחד לא מחבר אותם לתשובה שאפשר לפעול לפיה. זו בעיה של מוכנות ולא של תקציב, והעבודה נגזרת מגודל הסביבה: מה שחברה של שלושים אנשים צריכה כדי להיות מסוגלת לחקור אינו מה שחברה של שלוש מאות צריכה, ואף אחת מהן לא מגיעה לשם דרך רכישת מערך האבטחה הגדול ביותר שיש.
שאלות נפוצות
-
אתם לוקחים עבודת חירום מחברות שאינן לקוחות שלכם?
לא. התגובה מתחילה מתוך סביבה שכבר יש לנו גישה אליה, שאנחנו כבר מכירים את מודל הזהויות שלה וכבר מנהלים את תחנות הקצה שלה. להיכנס לסביבה לא מוכרת באמצע אירוע מבטל את שלושת אלה, וחלק ניכר מהיום הראשון הולך על להשיג אותם. אם אתם באירוע פעיל ואינכם לקוחות, אתם צריכים חברה שמתמחה בתגובה לאירועים ויכולה להיכנס לפעולה מיד.
-
אתם מספקים ניטור SOC או MDR מסביב לשעון?
לא כמרכז ניטור מאויש, והפער הזה קטן ממה שהוא נשמע. טלמטריה, יכולות זיהוי, התראות, תהליכים אוטומטיים ואינטגרציות תגובה ממשיכים לעבוד בין אם מישהו מסתכל על מסך ובין אם לא. אירועי סיכון זהות שהוגדרו לכך יכולים להרים התראה או להדק גישה, וזיהוי בתחנת קצה יכול להפעיל בידוד היכן שהפלטפורמה והתצורה תומכות בכך, ושניהם מגיעים לאנשים שצריכים לדעת דרך הערוצים שהם כבר עובדים איתם. עבור חברות קטנות זה לא פעם כיסוי מעשי משמעותי, שנבנה ברובו מפלטפורמות שכבר ברישוי, עם ריכוז טלמטריה או SIEM היכן שהסביבה מצדיקה זאת.
מה שבאמת נפרד הוא ניטור אנושי רציף. תור אנליסטים שצופה מסביב לשעון הוא שירות MDR או SOC, ואם זו הדרישה אפשר להוסיף אותו מעל אותה ארכיטקטורה במקום להחליף אותה. הוא לא נכלל כאן מכללא.
-
מה כוללת בחינת מוכנות בפועל?
מה שאתם יכולים לחקור עכשיו: כיסוי כלי הפורנזיקה, שמירת יומני ביקורת ודרכי האיסוף, שלמות מלאי הנכסים והזהויות, היכולת לבטל sessions פעילים, והפערים בסמכויות ההחלטה שגוזלים שעות בזמן אירוע אמיתי. אתם מקבלים קו בסיס כתוב ורשימת תיקונים לפי סדר עדיפויות. בחינת מוכנות עומדת בפני עצמה כעבודה מוגדרת, בין אם אנחנו כבר מנהלים את הסביבה ובין אם לא. תגובה לאירוע חי היא החלק שתלוי בהיכרות מוקדמת איתה.
-
כמה זמן כדאי לשמור יומני ביקורת?
יותר מברירת המחדל, שקצרה ממה שרוב האנשים מניחים ומשתנה בין פלטפורמות ורמות רישוי. בחקירות נדרש לעיתים קרובות לחזור שבועות אחורה כדי לקבוע מתי הגישה התחילה, ולכן חלון של שלושים יום לא מספיק בדיוק ברגע שבו צריך אותו. צריך לדעת מהי תקופת השמירה בכל פלטפורמה ולהאריך אותה כשצריך.
-
האם EDR מספיק בפני עצמו?
לא בפני עצמו, ולא מפני שהוא חלש. פלטפורמת EDR או XDR עדכנית מזהה, אוספת ראיות ומגיבה בשכבת המכשיר, כולל בידוד של תחנה כשצריך. מה שאין בה הוא שאר הסביבה: לאיזה מידע ב-SaaS הייתה גישה, האם נעשה שימוש חוזר באותם פרטי גישה במקום אחר, ומה מראה היסטוריית ההתחברויות והביקורת. כדי לקבוע היקף של אירוע על פני כל הסביבה צריך את אלה לצד התמונה מתחנת הקצה, וזו העבודה שהשירות הזה עושה.
-
מי כותב את דוח האירוע?
אנחנו, בסביבות שאנחנו מנהלים. הדוח כולל ציר זמן, נתיב כניסה, היקף, מידע שאליו ניגשו, פעולות בלימה, גורם שורש וסטטוס תיקונים, ונכתב עבור הנהלה, לקוחות, מבטחים ומבקרים, כשהפירוט הטכני נמצא מאחורי סיכום בשפה פשוטה.
בואו נבנה את יכולת התגובה כחלק מהסביבה שלכם.
שיחה של 30 דקות עם ג׳וני. נחזור אליכם תוך יום עסקים אחד.