1. Zen IT Technologies
  2. מוכנות ותגובה לאירועי אבטחה

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

תגובה לאירועי אבטחה היא לא משהו שמוסיפים אחרי שמשהו כבר קרה. אנחנו בונים את היכולת הזו כחלק מסביבת ה-IT שאנחנו מנהלים: איסוף ושמירת לוגים, נראות על תחנות הקצה, יומני ביקורת (Audit Logs), תהליכי התאוששות, והיכולת להריץ שאילתות או להפיץ סקריפטים לכלל התחנות כשצריך לבדוק משהו.

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

בואו נדבר

הבעיה

רוב הארגונים מגלים מה יכולת התגובה שלהם בזמן האירוע עצמו.

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

הפערים חוזרים על עצמם, ותמיד מתגלים מאוחר מדי:

  • אין כלי פורנזיקה מותקנים.

    איסוף הראיות תלוי בגישה פיזית למכשיר שעשוי להיות במדינה אחרת.

  • הלוגים כבר לא זמינים.

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

  • אין מלאי שאפשר להישען עליו.

    אף אחד לא יודע לומר אילו שירותי SaaS מחזיקים מידע ארגוני, או אילו service accounts קיימים.

  • אין הסכמה על סמכויות החלטה.

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

  • שום דבר לא נכתב בסוף.

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

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

  • יכולת תגובה שנבנית לתוך הסביבה

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

  • מתחילים מקו בסיס ברור

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

  • תכנון תגובה

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

  • בדיקה ופעולה בכלל הסביבה

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

  • המשכיות עסקית והתאוששות

    התגובה לא מסתיימת כשהאירוע נבלם. גיבויים, תהליכי התאוששות, בדיקות שחזור ותוכנית ההמשכיות העסקית צריכים להיות חלק מסביבת ה-IT, ולא מסמך שמכינים רק כשהמבקר מבקש אותו.

    במקומות שבהם הדבר רלוונטי, אנחנו בונים ומנהלים את הסביבה בהתאם לדרישות הרלוונטיות של ISO/IEC 27001 ו-ISO 22301, ובהסתמך על ההנחיות של ISO/IEC 27031 למוכנות מערכות ICT להמשכיות עסקית. אותה תשתית שמאפשרת לנו להבין מה קרה היא גם זו שעוזרת לעסק להמשיך לפעול ולהתאושש.

  • תגובה לאירועי אבטחה וחקירה דיגיטלית

    זיהוי, תחקור, בלימה וטיפול באירועי אבטחה הקשורים לתחנות קצה, זהויות, שירותי ענן וספקי צד שלישי. הטמעה והפעלה של כלי פורנזיקה על פני כל הצי; איסוף וניתוח יומני ביקורת מ-Google Workspace, Microsoft 365 וממערכות ניהול קוד. ניתוח גורם השורש (Root Cause Analysis) וכתיבת דוח אירוע פורמלי. הקשחה לאחר אירוע, פיתוח יכולות זיהוי ומעקב אחר תיקונים.

  • ניטור, התראות וזמינות

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

מסמכים טכניים באנגלית

איך מנתחים גל התראות רוחבי

צורת הגל מזהה את מקורו מהר יותר מניתוח הקובץ עצמו.

עוד בנושא

איך זה עובד

  1. בחינה.

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

  2. תיקון.

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

  3. תכנון.

    נהלי תפעול וסמכויות החלטה, מוסכמים וכתובים.

  4. תחזוקה.

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

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

דוגמאות מהשטח

  • יכולת פורנזית שהוטמעה לפני שנדרשה.

    חברת טכנולוגיה

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

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

    פלטפורמת SaaS

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

  • יכולות זיהוי נבנו מחדש תוך כדי קמפיין תקיפה פעיל.

    חברת טכנולוגיה

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

  • תקלה רוחבית ב-EDR נבלמה ונפתרה מול הספק.

    חברת טכנולוגיה

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

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

למי זה מתאים

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

שאלות נפוצות

  • אתם לוקחים עבודת חירום מחברות שאינן לקוחות שלכם?

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

  • מה כוללת בחינת מוכנות בפועל?

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

  • כמה זמן כדאי לשמור יומני ביקורת?

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

  • האם EDR מספיק בפני עצמו?

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

  • מי כותב את דוח האירוע?

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

בואו נבנה את יכולת התגובה כחלק מהסביבה שלכם.

שיחה של 30 דקות עם ג׳וני. נחזור אליכם תוך יום עסקים אחד.

בואו נדבר