תחקור ותגובה בענן Cloud Forensics and Incident Response
טכנולוגיות בענן, אפליקציות ענניות, קוברנטיס וכן הקונטיינריזציה הפכה לגורם דומיננטי ועמוק בתוך המיינסטרים. ארגונים קטנים וגדולים מעבירים ומפתחים אפליקציות בענן ונמצאים חזק במירוץ הטכנולוגי – אותו מירוץ מוכר שהחל עם המעבר לענן לפני שנים ספורות.
כידוע, הפעלה ופיתוח של אפליקציות מספקת מדרגיות ויעילות בעולם טכנולוגי מודרני שהולך וצובר תאוצה. צוותי DevOps ופיתוח עושים כל העת צעדים ופעולות באימוץ כלים מגוונים וחדשים, תהליכים מתודלוגיות ועוד. לצד היתרונות הברורים של אפליקציות וחדשנות, נוצרו פערים ובעיות חדשות, כמו אלה של אבטחת מידע בענן, ביניהם אחת השאלות הגדולות והם, כיצד לבצע תחקור, פורנזיקה ותגובה בענן.
המאמר הינו חלק מסדרת מאמרים אשר נוגעים באפשרויות של תחקור ותגובה בקוברנטיס ומביא איתו תובנות, טיפים ומידע על זיהוי תקיפה, כלים מומלצים ושיטות עבודה.
אתגרי אבטחה בענן
אבטחת מידע וסייבר בענן הוא אתגר עצום ומכיל בתוכו אינספור אתגרים, קטנים וגדולים. נוסיף לכך את המשמעויות של סביבות מולטי-ענניות שמתבססות בימינו על תצורות של מולטי-וורקלואד, ובפרט מולטי-קוברנטיס. לצד כל זה, נוסיף את החיבור לסביבה המקומית וערבבנו שמחה בשמחה.
הבעיות העיקריות של אבטחה בענן נחלקות למספר נקודות עיקריות:
תצורה והגדרות ברירת מחדל – וונדורים בענן ואף ספקי אבטחה בענן משחררים טכנולוגיות וכלים שהם קודם כל לטובת פרודוקטיביות ושימוש של הכלי או המוצר. לדוגמה, יצירת טננט חדש של Azure AD כוללת הגדרה דיפולטית של יצירת טננט ע"י כל משתמש רגיל. דוגמה נוספת היא, בענן של AWS נוצר אובייקט ניהול דיפולטי שמקבל הרשאות גבוהות בעת יצירת חשבון.
הגישה הזאת היא נחלת הכלל ואיננה מאפיין של וונדור כזה או אחר, ולכן אנו חייבים להיות מודעים למצבים שבהם תצורות והגדרות ברירות מחדל מגיעות עם פערי אבטחה.
טיפ: להשאיר תצורות או הגדרות ברירת מחדל בענן זה אומר להשאיר חשיפה ופערים – יש לשנות תצורות והגדרות ברירת מחדל.
ניתן לראות באימייג המצורף את האפשרות של יצירת טננט ע"י יוזר רגיל.
מיסקונפיג – אדמינים, אנשי פיתוח ואף אנשי אבטחה עושים כל העת שינויים בתצורות והגדרות במערכות וכלים שונים. לעיתים קרובות אנו יוצרים מיסקונפיגורציה בעצמנו.
לדוגמה, תשתית IAM אשר מכילה תנאים וחוקים להקשחת גישה. לצורך העניין, הגדרת חוקים ותנאים שהם חלק מתוך תהליך הקשחת זהויות ואף חלק בתהליך של מימוש Zero-Trust. ביצירה של תנאי אכיפה המתיר כניסה אנו חייבים לאכוף תנאי נוסף שמגביל את הגישה ויוצר הלימה בין שני התנאים.
במצבים מהסוג הנ"ל שהם נפוצים ואין הלימה בין תנאי מתיר אל מול תנאי מגביל אנו משאירים פער ונקודות כניסה שניתנות לניצול במרחב.
תרחיש שמאפשר לנצל פערי הגדרות בתשתית Azure AD ברמת מכונה
Bypass the Cloud – Azure AD CA Device Scenario (misconfig.io)
פגיעויות וסיכונים – ספקי ענן וכלי אבטחה מכילים פגיעויות שניתנות לניצול, כמו השניים של CloudFormation וכן Glue (וכאלה ישנן עוד הרבה). הפגיעות מאפשרת לתוקפים להדליף קבצים רגישים שנמצאו במכונה הפגיעה ולהפוך בקשות בצד השרת (SSRF) לרגישות לחשיפה לא מורשית של אישורים בתשתית AWS פנימיים.
למאמר המלא BreakingFormation: Orca Security Research. פגיעויות מהסוג הנ״ל קיימות בשטח ונחשפות לעיתים קרובות.
שטח תקיפה חיצוני – המעבר לענן או סביבה מולטי-עננית מרחיב את שטח התקיפה החיצוני בצורה מהותית, וכזאת שאיננה ניתנת למדידה ברמת היומיום (תלוי בקצב השינויים בענן).
כמות הנכסים החיצוניים שנמצאים בחשיפה עלולים להיות רגישים, או כאלה שעלולים להוביל לנקודות תקיפה. הבעיה הגדולה היא שאין אפשרות לדעת במקרים רבים מי מבצע פעולות גילוי, סריקה ואנומרציה מול נכסים חיצוניים בענן, או מי מתחיל בשלב תקיפה ראשוני.
במקרים רבים הזיהוי ע"י כלי האבטחה והניטור נעשה בשלב מאוחר מידי, ואף במצב שישנה כבר גישה ראשונית אל אובייקט.
כיום, בסביבה ממוצעת ישנם לפחות שני ספקי ענן, ובמקרים אחרים מדובר על שלושה וארבעה ספקי ענן, כמו כן, ישנם תרסרי תצורות של מולטי-וורקלואד ומולטי-קוברנטיס. במצב כזה שטח התקיפה החיצוני הוא רחב, דינמי ואינו מוכר כלל.
מאמר על משטחי תקיפה ונכסים חיצוניים משטחי תקיפה וכלי Defender EASM.
אובייקט אמצע – "אובייקטים ביניים" הם כל אובייקט/תוכנה/אפליקציה/רכיב/סוכן שמוגדר ברמת רכיב בודד, או בין שני רכיבים, ואף בין שני עננים. אובייקט אמצע גורם לחשיפה ופערי אבטחה (פערים בהגדרות, פגיעויות ועוד). למשל, סוכנים שמוגדרים על מכונות וירטואליות, סוכנים שמוגדרים עם תלויות מול OSS עצמאי, ואובייקטים שמוגדרים עם מנגנון הזדהות (Local Auth) עצמאי ולא מול תשתית IAM מנוהלת. בסביבה עננית ממוצעת ישנם תריסרי אובייקטים כאלה.
הנקודות המוזכרות מעלה הם נקודות תקיפה פוטנציאליות ועלולות ליצור חשיפה בעלות משמעות גבוהה בכל סביבה עננית. סביבות ענניות, מולטי-ענניות וסביבות היברידיות מכילות את כל הנקודות המוזכרות ללא יוצא מן הכלל! מכאן זה לוקח אותנו להבנה שהרבה אינו ידוע בענן, ולכן ציר זמן התקיפה בענן הוא לעיתים קרובות, ארוך מהרגיל.
ציר זמן תקיפה בענן
רגע לפני שמדברים על תחקור ותגובה בענן ועל האפשרויות של תחקור ותגובה בטכנולוגיות כמו קוברנטיס ואפליצקיות Cloud-Native כדאי להבין את כלל הגורמים שנמצאים במשחק, תוקפים באשר הם (מדינתי ואחר), מורכבות טכנולוגית, דינמיות וחדשנות, ריצה טכנולוגית, עומס על צוותי אבטחה, מחסור באנשים, פערי ידע – כל אלה נותנים לצד התוקף יתרון משמעותי, ולכן התוצאה – השפעות התקיפה בענן וציר הזמן לזיהוי והכלה.
ציר זמן תקיפה קיים בכל תקרית סייבר בין עם מקומית או עננית, וציר זמן נותן לנו הבנה כללית על נקודות חשובות במהלך התקרית, פעולות שבוצעו ע"י התוקף, פעולות שבוצעו כחלק מתוך מענה, תגובה ותחקור, ומאפייניםמ נוספים שעלולים להשקפיע על מהלך התקיפה והתחקור.
ציר זמן התקיפה בענן שונה מאשר ציר זמן תקיפה מקומי בגלל שהוא מושפע מגורמים נוספים שאינם קיימים בסביבה המקומית, גורמים כגון, מודל האחריות המשותף (SRM), הבנת הפילארים המרכזיים (PaaS, IaaS וכו), דינמיות טכנולוגית.
אז מהו ציר הזמן לזיהוי תקיפה ענן? ציר הזמן, אותו Cloud Attack Timeline שמכיל את פרק הזמן לזיהוי תקיפה בענן לוקח בין 180-200 ימים, ועוד 45 ימים תגובה והתאוששות. בזמן הממושך שתוקף נמצא בענן הוא עלול או מבצע מספר פעולות, כמו תנועה רוחבית בתוך הענן שנפרץ, או שמבצע תנועה רוחבית לאורך ספקי ענן נוספים.
הניסיון בשטח מלמד כי תוקף שיש לו אחיזה בסביבה עננית אינו ממהר לנוע לתוך סביבה מקומית, ולכן חשוב להדגיש כי אחוז המקרים שבהם התוקף נע לתוך הסביבה המקומית אינו גבוה כלל.
בעוד שציר הזמן של זיהוי הפרות ופרצות עלול להיות ארוך, זמני התגובה אינם מהירים וחסרים בפרטיקות תגובה, מכאן, תחקור ותגובה בענן אינם נמצאים בהלימה עם סביבות מקומיות ועם מתודלוגיות קלאסיות של DFIR המוכר.
זיהוי, תחקור ותגובה בענן שונים מאשר הסביבה המקומית, ובמקרים היותר פשוטים של זיהוי תקיפה בענן, ובפרט ברכיבי SaaS הניסון בשטח מלמדים אותנו כי ישנם הבדלים עצומים. כאשר זה מגיע לרכיבי IaaS / PaaS / FaaS המצב גרוע הרבה יותר.
התרשים הבא הוא תרשים כללי שנוגע באלמנטים המרכזיים של ציר זמן תקיפה בענן עם נקודות מרכזיות של פעולות התוקף, זיהוי תקיפה בענן, זמני שהייה במרחב הענני, וכן זמני תגובה והתאוששות. מדובר על פרק זמן ארוך מאוד.
הגישת לשמירת לוגים בענן
אחת הנקודות הבולטות בענן הוא תיעוד. תיעוד ושמירת לוגים בענן היא שונה מאשר הסביבה המוקמית ולמרות שמדובר על לוגים עדיין אפשר לראות פערים רבים. הפערים יכולים להיות גם במקרים בהם ישנו SIEM מרכזי שאליו זורמים כל הלוגים.
שמירת לוגים – אחת הבעיות הנפוצות בענן היא שמירת לוגים לפרקי זמן קצרים ואף קצרים מאוד, בחלק מהמקרים נתקלתי בסיטואציות של שמירת לוגים עד 90 יום לאחור, ובמקרי קצה גם פחות מכך. שמירת לוגים צריכה להיות 180 יום לאחור, ולא פחות מכך!
לוגים בעלי ערך – שמירת לוגים צריכה להיעשות לטכנולוגיות, רכיבים ונכסים בעלי ערך, ואם אפשרי, בהלימה אל Business Objective, ולא הזרמת לוגים חסרת ערך ללא רקורדים בעלי ערך שמציפים את האנליסטים בנתונים ואינו נותן ערך בפיתוח תוכן בתשתית SIEM.
הרשאות ושינויים – גישה לשינוי לוגים היא חלק מתוך העקרון של ניהול לוגים וישנם ספקי ענן שמאפשרים למחוק לוגים בסיסיים – במצב כזה אנו מאבדים יכולות תיעוד ותחקור.
תיעוד חיצוני – הבנת משטח התקיפה החיצוני בענן הוא גורם מאוד קריטי, ולכן צריך לדעת מהם משטחי התקיפה בענן ולתעד פעולות, שינויים ושמירת לוגים.
הדוח של 2022 Data Breach Investigations Report | Verizon נותן נקודת מבט על תקריות, כולל תקריות בענן.
דיון נוסף בנושא Cloud Attack Timeline בפוסט קצרצר שפורסם ב Post | LinkedIn.
אתגר התחקור בענן
האתגר של תחקור ופורנזיקה בענן, ובפרט קוברנטיס וקונטיינרים היא לבצע תחקור בסביבות ארעיות ודינמיות במטרה לחלץ את כל הנתונים הרלוונטיים, וכל זאת מבלי להפריע לסביבה הדינמית, ובהתאם לסיטואציה נוכל לזכות את המערכות כאשר מתרחש אירוע אבטחה באחת מהסביבות מבלי לפגוע בתהליכי פיתוח, בסביבת הייצור ולאפשר המשכיות אפליקטיבית ועסקית.
תחקור ותגובה בענן אינו מתחיל מכלי אבטחה, אלא מגישה ושינוי מיינדסט בלבד.
תחקור ופורנזיקה ידועים כפעולות שאינן פשוטות, לעיתים מורכבות במיוחד, בטח שזה מגיע לענן, ובפרט לקוברנטיס שבנוי ממאות רכיבים ורכיבי משנה. במקרה של תחקור בענן וכן תחקור קוברנטיס עולות שאלות מהותיות, כמו:
- איך מבצעים תחקור על מערכות דינמיות שבהן POD יכול לעלות ולרדת בכל רגע נתון?
- האם ניתן להבין מה קורה בסביבת קוברנטיס מסועפת? סביבה עם מאות קלאסטרים ואבני בניין.
- מהם השלבים כאשר ישנם קריאה לאימייגים? או קריאה לרכיבים אחרים?
- בארכיטקטורה לא נכונה ישנה השפעה על תחקור ושמירת ראיות.
- תלויות בגורמים חיצוניים כחלק מתהליך הקמה של סביבות.
- האם צריך לבצע תחקור על הגורמים הפנימיים במערכת או שמספיק להבין את המעטפת (זהויות, אחסון, גישה לאפליקציות)?
- האם ישנם רכיבים בקוברנטיס אשר שומרים מידע בהתקני אחסון אחרים בענן?
- האם ישנם כלי CSPM/CWPP/CNAPP?
- האם יש תלויות החיצוניות? והאם הם חלק בשמירת ראיות?
- האם תהליכי פיתוח יהיו חלק במנגנון התחקור?
אלה הם רק חלק קטן מסריה של שאלות הצריכות להישאל בהבנה של הצורך בתחקור סביבת קוברנטיס, בסביבות Cloud-Native וגישת התחקור שכולל תהליכם, כלים, וחשוב מכך אנשים.
בשל אופיים הטכנולוגי, אפליקציות ענניות (Cloud-Native Apps), קוברנטיס וקונטיינרים התגלו כבעייתים עבור גישות DFIR מסורתיות, ואכן, תהליך DFIR קלאסי שכולל בין היתר ניתוח פורנזי ופוסט–מורטם אינה פעולה פשוטה או אפשרית בסביבות ענניות דינמיות, ובפרט בסביבות מהסוג הנ״ל.
ספקי הענן והטכנולוגיות הרבות הובילו למצבים של הכנסת מתודולוגיות ושיטות עבודה חדשות, דינמיות ומומלצות של תחקור ופורנזיקה שיש לעקוב אחריהן בכדי לזהות ולהגיב לתקיפות פוטנציאליות ותקריות סייבר.
כמו שאני קורא לזה Cloud Forensics and Incident Response (בקצרה CFIR), או Kubernetes Forensics and Incident Response.
מה זה CFIR
לפני שמתחילים להכות בכלים, בטכנולוגיות, אינטגרציה ואיך מבצעים. כדאי רגע לעשות בריף על CFIR בכדי לחבר את הנקודות לשלבים הבאים. (וגם למאמררים הבאים).
זיהוי ענני ותגובה לתקריות (CFIR) הוא תחום אבטחת הסייבר הכולל טכניקות, מתודולגיות ושיטות עבודה מומלצות שיש לאמץ כאשר מתרחש אירוע פוטנציאלי או תקרית סייבר בענן שמצריכה התמקדות בזיהוי, תחקור ותגובה. במקור, התחום עצמו של DFIR אינו חדש וקיים איתנו שנים ארוכות ורבות, ומוכר כתחקור ופורנזיקה למערכות מקומיות, תוכנה וחומרה.
זיהוי פלילי ותגובה לתקריות ענן מבוססות על ניתוח ואחסון קפדניים של עדויות וראיות דיגיטליות בתקרית אבטחה, אך גם תגובה להתקפות באופן שיטתי ומתוזמן. כתוצאה מכך, הם מאפשרים להקטין במעט את ההשפעה על תקרית סייבר, מפחיתים את משטח התקיפה ומונעים אפיזודות עתידיות.
ניתוח ותגובה לתקריות ענניות מצריך בתחילה הבנה מעמיקה של מודל האחריות המשותף (SRM) ושל הפילארים המוכרים בענן המוכר, קרי, IaaS/SaaS/PaaS/FaaS. מדוע יש לזה חשיבות? כי כל פילאר כזה בענן מגיע באופן שונה, לאחד יש מכונה, ולשני רק אפליקציה ואין אפשרות להתייחס לשניהם באותה מידה.
למשל, המאמר הזכיר מוקדם יותר את הבעיות של תיעוד ולוגים, ולכן כל פילאר טכנולוגי מתעד לוגים בצורה שונה, ישנו תיעוד ושמירת לוגים שהינם חופפים בין כל הפילארים, וישנו אחרים שהם ייעודים לכל חלק ושכבה טכנולוגית בפילאר מסוים. במצב כזה, ישנה השפעה ישירה ומהותית על פעולות אשר קיימים בשלבי הכנה, זיהוי ותחקור.
התרשים הבא מתאר את הרכיבים שיש בכל פילאר בסביבה המקומית, סביבה העננית, ואחריות בתוך צוותי האבטחה. מכאן אנו למדים האפשרויות זיהוי ותחקור מול הפילאר של SaaS אינו יכול להיות זהה באותה מידה לפילאר של FaaS.
לצד התרשים המתואר מעלה יש לכל ספק ענן מודל אחריות (SRM). העקרונות דומים בכולם, אך עדיין, לכל ענן יש את הפרטים הקטנים בגישה שלו למודל האחריות ואלה בתורם משפיעים גם כן על הגנה, יזהוי ותחקור.
המודלים הבאים של Azure ושל AWS מציגים את העקרונות, הבדלים בין פילארים ואחריות של כל צד.
בשטח אפשר לשים לב לבעיה במודל האחריות, והיא, ככל שהאחריות על הלקוח היא קטנה יותר מבחינתה טכנולוגית וגם מבחינת אבטחה והגנת הסייבר, כך הפערים גדולים יותר ויוצרים תצורות שגויות, מיסקונפיג ופערי אבטחה.
כאמור, מודל האחריות משפיע באופן ישיר על מספר אלמנטים בתהליך CFIR, החל מהכנה, דרך זיהוי ועד פוסט-מורטם, ומכך משפיע על תחקור, שמירת ראיות ותגובה בהתאם לפילארים המוכרים.
תרחיש במכונות Azure
בענן יש אינספור תרחישים למענה ותגובה, בין אם זהויות, מכונות ענניות, אחסון (Blob/S3), מכונות וירטואליות, בסיסי נתונים וכן הלאה שיכולים להציף לנו ארטיפקטים מגוונים.
אנו חייבים לוודא שארטיפקטים וראיות דיגיטליות מספקות את הצורך כחלק מדרישות משפטיות וכחלק מתהליך של שמירת הראיות, המוכר כנוהל Chain of Custody, (בקצרה CoC). לאורך התהליך אנו חייבים לוודא את נוהל CoC ואת התקפות שלו. אחסון ראיות דיגיטלי חייב להפגין בקרת גישה נאותה, הגנה על נתונים ותקינותם, ניטור והתראה, רישום וביקורת וזאת בהתאם לדרישות.
ישנם תרחישים רבים של יצירת אזור ייעודי לטובת תחקור, תגובה ושמירת ראיות. במקרה היותר פשוט של שמירת ראיות במכונה וירטואלית אנו צריכים להכין מספר דרישות ורכיבים:
- להכין תהליכי עבודה.
- להכין רכיבים (Storage, Log Analytics, Key Vault).
- לוודא דרישות רוגלוציה.
- לוודא שיקולים.
- בפרט ראיות (הפקה, שמירת,שלמות).
- פריסת התשית באופן אוטומטי.
- ניטור התהליך.
- ביצוע סימולציות.
פירוט התהליך Computer forensics chain of custody in Azure – Azure Example Scenarios
בעיה נפוצה בשטח. פער מהותי בסביבות ענניות של Azure או של AWS היא שאין Azure Subscription או AWS Account ייעודי לטובת אבטחה ובפרט תחקור ותגובה, או כזה של ה SOC. כאשר מדובר על CFIR, אין אפשרות לאסוף עדויות וראיות, לתחקר ולהגיב לתקריות בצורה המיטבית.
תרחיש AWS S3
במקרה של AWS ישנם מפרטים וסאמפלים בפילארים של IaaS/PaaS שמהם ניתן להתחיל, כמו במקרה הזה של גישה לא מכוונת לשירות האחסון Amazon. התבנית של IRP-DataAccess מתאר את שלבי התגובה לגישה לא מכוונת אל שירות האחסון, S3.
שלבים אלה מבוססים על המדריך לטיפול בתקריות אבטחת של NIST (סעיף 800-61) שניתן להשתמש בו בכדי:
- לאסוף ראיות.
- להכיל ולמגר את האירוע.
- התאוששות מהאירוע.
- ביצוע פעילויות לאחר האירוע.
- ביצוע פוסט-מורטם ופידבק.
לתהליך המלא IRP-DataAccess Playbooks.
תוכנית תגובה לתקריות
כאשר מתכוננים לתקרית אבטחה, כל ארגון צריך ליישם פעולות וטכניקות IRP (תהליך תחקור, תגובה והכלה), וכל IRP צריך להיות מותאם לסביבה הארגונית – Tailor-Made! התהליך המתועד קובע את ההנחיות שיש לנקוט במקרה של הפרה.
תהליך תגובה (IRP) חייב להיות שונה עבור כל סביבה, וניתן לסכם אותו במספר שלבים עיקריים:
זיהוי מהיר ועמוק של התקיפה והסיכונים הכרוכים בה יכולה למלא תפקיד מפתח ומרכזי בתהליך כולו. שלב זה כולל בדרך כלל את כל אירועי האבטחה, יומני הרישום והדוחות הקשורים לסביבה המושפעת.
תיאום לאחר זיהוי אירוע אפשרי (חשד לתקרית), צוות התגובה צריך להעריך האם האירוע מייצג אירוע אבטחה אמיתי ואת היקפו. כתוצאה מכך, נדרש להחליט איך להגיב ובאיזה אופן. לתגובה הראשונית יש השפעות רבות, טכנולוגיות, עסקיות ועוד.
חקירת הגורם לתקרית עצמה, הגבלת השפעתה ובידודה במידת הצורך. בשלב זה, על הצוות לטפל בסיכוני האבטחה וליישם אמצעי תיקון. בסופו של דבר, הוא יכול לשחזר מערכות, נתונים ושירותים מושפעים מגיבויים, ואפילו לתקן סביבות מושפעות.
יישום מדיניות שיפורים בתקרית סייבר מייצרת הזדמנות חדשה להכשרה של אנשים והקשחת תקני האבטחה בענן. נצלו זאת.
השלבים המוזכרים כאן הם השלבים שמבוססים על NIST או CIS ולכן ניתן להרחיב את השלבים ולפרק אותם לתתי שלבים נוספים, והכל לטובת ביצוע התאמות סביבתיות.
טיפ: הכנת IRP הוא Tailor-Made ולכן כדאי לתפור את הפתרון הנכון לסביבה והשינויים בה.
איך נראה תהליך IRP בקוברנטיס? המאמר Kubernetes Incident Response flow נוגע באפשרויות המגוונות של הכנת תהליך בקוברנטיס, תובנות, תרשים תגובה וטיפים נוספים.
כלים בתחקור קוברנטיס
לצד יצירה והבנה שלכל גורם בתהליך תגובה אנו גם צריכים להבין שכלים מסייעים לנו לקדם תהליך תגובה באופן מהותי, החל מהשלבים המוקדמים ועד לשלבים המאוחרים, קרי, משלב הזיהוי, חקירה ותגובה. חשוב להדגיש כי אנשים עושים תחקור ופורנזיקה ולא כלים או מערכות.
כל השלבים שתוארו קודם לכן צריכים תמיד להיות נתמכים על ידי כלים שיכולים להקל על החקירה והתגובה של ההתקפה. על ידי אכיפתם, ניתן לקבל נראות עמוקה על התהליך והרכיבים שנמצאים בשליטה, ואנו צריכים לאחסן ראיות באופן אוטומטי באחסון מרוחק.
יתר על כן, אנו צריכים לנטר את המשאבים הקיימים בכדי לזהות מקרים בלתי צפויים של עומסי עבודה (וורקלואדים), לקבל התראות במקרה של תקריות או תעבורת רשת חשודה וכתוצאה מכך להגיב אליהם באופן מיידי, אוטומטי או ידני.
כלים ישנם למכביר וחיפושים קלים ברשת יכולים להניב תוצאות של אינספור כלים בכל קטגוריה. הכלים שישמשו במאמרים אלה במהלך CFIR:
מערכת SIEM לניטור ותגובה
מערכות SIEM מסייעות באיסוף ואחסון הלוגים, יומני רשת ואת ההתראות שנוצרו לסביבה המנוטרת. הגוף (SOC) שמתפעל את ה SIEM הוא הגוף שמגיב ראשון לתקריות, ולכן שיקול דעת של אנליסט עלול להיות קריטי במקרים של תקריות אמת. מערכת ה SIEM צריכה לתמול באפשרויות של איסוף מידע אוטומטי (במקרים שאין אפשרות לקבל לוג) וביצוע פעולות אוטומטיות, סמי-אוטומטיות וידניות.
במקרה שלי התשתית של Microsoft Sentienl נתנה את הביצועים הנדרשים כמערכת שידעה לחבר אליה את כל המערכות הנדרשות, ליצור אוטומציה עם כלים OSS צד שלישי ולתת תמונה מלאה ככל האפשר על נראות, זיהוי וסיוע לאנליסט במצבים של אירוע פוטנציאלי או תקרית.
כלי OSS
שמדובר על סביבות ענניות דינמיות ואפליצקיות Cloud-Native אנו צריכים סיוע של כלי OSS שיוכלו לסייע באיסוף, שמירה, ניתוח פורנזי, שמירת ראיות וכן הלאה. מערכת SIEM לבדן טובות ככל שיהיו ידח עם כלי CSPM/CWPP/CNAPP עדיין אינן יכולות לתת תמונה מלאה והוליסטית, וכן לאסוף את כל המידע ולסייע בתחקור, בטח שמדובר על סביבות דינמיות.
כלי האבטחה בענן שנמצאים בקטגוריה של כלי CSPM/CWPP/CNAPP אינם יכולים לבדם אינם כולים לבצע את הפעולות הנדרשות לטובת תחקור ותגובה כמו הכלים המתוארים מטה. כלים בודדים בלבד נמצאים בצעדיהם הראשונים של תחקור ותגובה בענן (CDR).
הכלים המתוארים מטה הם כלים המובאים על סמך ניסיון וחיבור בשטח בין הכלים ובין Microsoft Sentinel. ישנם ברשת כלים נוספים שיודעים לבצע את העבודה ואפשר לתפור אותם לפי דרישה אל מול מערכת SIEM כלשהיא.
פרוייקט Falco יכול לזהות ולהתריע על כל התנהגות הכרוכה בביצוע קריאות למערכת לינוקס. התראות יכולות להיות מופעלות על ידי שימוש בקריאות מערכת ספציפיות, הארגומנטים שלהן ועל ידי מאפיינים של תהליך הקריאה. לדוגמה, Falco יכול לזהות בקלות תקריות הכוללות:
- Shell שמבצע ריצה בתוך קונטיינר
- קריאה או גישה אל קובץ רגיש
- יציאות בינאריות שיוצרות חיבור רשת חשודים
Falco ניתן להרחבה ולמצבים בהם ניתן לבנות ולערוך ביישומים ותשתיות מקוריים בענן.
פרוייקט Falcosidekick מציע מנוע קוברנטיס שנועד לזהות תנועות חשודות ולבצע תגובה ברמת קונטיינר וקלאסטר של קוברנטיס. מכיוון שהוא יכול לעשות אינטגרציה עם Falco הראייה והתפוקות של Falcosidekick היא רחבה. במקרה של חיבור עם Falco ניתן לקחת את האירועים ולהעביר אותם לרכיבים ותוצרים אחרים.
Docker Explorer וכן Container Explorer הם פרויקטים שמסייעים בניתוח וביצוע זיהוי פלילי במערכות קבצים לא מקוונות של Docker. כאשר האחרון מאפשר לבצע תחקור אימייגים בדיסק עם יכולות של תחקור מרחבי שמות, קונטיינרים, תכנים, פלט JSON ועוד.
פרוייקט Kube Forensics מאפשר לקחת תמונת מצב קיימת של POD ואת כל הקונטיינרים לטובת ביצוע תחקור. במצב של תקרית ניתן לנתח את המצב האחרון של אותו POD ורכיביו ולקבל אינדיקציה לגבי הניתוח, ועל סמך הראיות נוכל לקבל אינדיקציה האם מדובר על אירוע פוטנציאלי או תקרית.
פרוייקט Cloud Forensics Utils הוא פרויקט נוסף שמפשט את איסוף הראיות לבדיקה באמצעות סט כלים.
לסיכום, כלים ותכנון האסטרטגיות הנכונות מאפשרים לעקוב ולאסוף את הראיות של הסביבות והאפליקציות, מה שהופך את הניהול והחקירה לפחות מורכבים ומעט אוטומטיים. הקמת סביבת תחקור לקוברנטיס אינה דבר שמתאים לכל סביבה ומצריך הבנה של איזה כלי (פרויקט) כדאי ליישם כחלק ממענה ותגובה לתחקור תקריות בענן.
מאמר מעולה