.gif)
.jpg)
סקרי אבטחת מידע מהווים כלי אינטגרלי ביכולתם של אירגונים לאמוד פרמטרים שונים הקשורים בהגנת המידע, מוכנות העסק לתקריות, בקרות ויעילותן, ועוד. קיימים סוגים שונים של סקרי אבטחת מידע הבוחנים חלקים שונים מארגון, ובהתאם לזאת מניבים תובנות אשר ייתמכו בארגון בחלק הנבחן. בדיקות חדירות הן סוג של סקר אבטחת מידע בו הצוות הבודק מחפש פגיעויות בתשתית, מערכת, או אפליקציה מסוימת. בדיקות מסוג זה מקנות מימד של הבטחת חוסן למערכת הנבדקת. קיימות מתודולוגיות שונות לבדיקות חדירות: White-box, Gray-box, Black-box, כאשר אופן הביצוע של כל אחת מהן שונה במהותו ומקנה זווית שונה לבדיקת החדירות. במאמר זה אתמקד בבדיקה מסוג Gray-Box בסביבות ענן. בבדיקה זו, לבודק יש ידע על המערכת וגישה כלשהי.
הכנות בטרם מתחילים בבדיקה
כשמבצעים בדיקת חדירות בענן, ישנם שיקולים מסוימים שנצטרך לקחת בחשבון על מנת לבצע בדיקה תקנית ואיכותית. בשלב ההכנה לבדיקה על מערכת מבוססת ענן יש לבחון את הסכם רמת השירות (SLA) ומדיניות בדיקות החדירות של ספק הענן. מודל האחריות המשותפת משתנה בין מודל שירות אחד לאחר, ובהתאם לו תחומי האחריות בבדיקות החדירות. אם השירות אותו אנו צורכים ומעוניינים לבדוק הינו מסוג SaaS, יש למקד את הבדיקה רק בשכבות ה-Data וה-Identity. אך אם השירות הינו IaaS, יש להבין שגם שכבת ה-Application וה-OS יכללו בבדיקה. על בסיס מודל האחריות המשותפת המתאים אנחנו יכולים לגזור מה הם האיומים הרלוונטיים לטובת מיקוד הבדיקה, ובנוסף מה באחריותנו כלקוחות באופן כללי. בהמשך לזאת, ספקי ענן מסוימים מצהירים על אחריותם בנושאי אבטחת מידע ובדיקות חדירות במרכיבים וחלקים ספיציפיים מהתשתית שהם מספקים, בזמן שהשאר נכנסים תחת אחריות הלקוח. על מנת לבצע בדיקה תקנית שלא עוברת על מדיניות ספק הענן בנושאים אלו חשוב להבין אותה לעומקה ולתכנן את הבדיקה בהתאם. לאחר ההכנה, נתכנן את הבדיקה על בסיס המידע שאספנו בהכנה, וננסה לשדרג כל שלב בבדיקת החדירות לטובת התאמה טובה יותר.
תכנון, הגדרה וגילוי הבדיקה
בשלב זה, נגדיר את היקף (Scope) הבדיקה בהתאם לפרטים שנאספו. אם יש מרכיבים, חלקים, או שירותים מסוימים בתשתית ספק הענן אשר אסורים לבדיקה, נבהיר זאת בהגדרת ההיקף. בהתאם לזאת נגדיר אילו מרכיבים, חלקים, ושירותים מתשתית הענן הינם חלק מהבדיקה. עוד בשלב התכנון, אם מתבצע Threat Modeling ברמה מסוימת כדאי לקחת בחשבון את איומי הענן המובילים והרלוונטיים למודל הענן שבו שוכנת המערכת המיועדת להבדק. מומלץ בנוסף גם לשאול את ספק הבדיקה על מידת הניסיון שלו עם תשתית הענן הספיציפית, ולבקש דוגמאות לבדיקות מוצלחות.
ביצוע בדיקת חדירות מסוג Gray-Box מתחיל באיסוף מידע וגילוי, כך שגם בשלב ראשוני של הבדיקה ניתן למקסם את התוצאות על ידי חיפוש מידעים הקשורים לענן כגון מפתחות, קישורים, קבצי קונפיגורציה ועוד. בשלב הגילוי כדאי לוודא את ההיקף שהגדרנו בשלב התכנון, ולפענח מהם המרכיבים מתשתית הענן אשר נמצאים באחריותנו ויכולים להתגלות פגיעים (חקירת רשומות DNS עשויה להיות אפילו יעילה מהרגיל). תוצאות הבדיקה מגיעות כדו"ח שמונה את הפגיעויות, פירוטן הטכני וחומרתן. מכיוון שפורמט הדו"ח משתנה מספק לספק ובזאת ארגון המידע מהבדיקה, כדאי לבקש מהספק המבצע את הבדיקה להקדיש חלק ספציפי מהדו"ח למידע הקשור באופן ספיציפי לתשתית הענן. מידע זה יכול לכלול את מרכיבי תשתית הענן שזוהו, מידע שנאסף בשלב הראשוני של הבדיקה, פגיעויות שנמצאו וכו'.
מאת: עוז אבנשטיין, מנכ"ל Avensec
סקרי אבטחת מידע מהווים כלי אינטגרלי ביכולתם של אירגונים לאמוד פרמטרים שונים הקשורים בהגנת המידע, מוכנות העסק לתקריות, בקרות ויעילותן, ועוד. קיימים סוגים שונים של סקרי אבטחת מידע הבוחנים חלקים שונים מארגון, ובהתאם לזאת מניבים תובנות אשר ייתמכו בארגון בחלק הנבחן. בדיקות חדירות הן סוג של סקר אבטחת מידע בו הצוות הבודק מחפש פגיעויות בתשתית, מערכת, או אפליקציה מסוימת. בדיקות מסוג זה מקנות מימד של הבטחת חוסן למערכת הנבדקת. קיימות מתודולוגיות שונות לבדיקות חדירות: White-box, Gray-box, Black-box, כאשר אופן הביצוע של כל אחת מהן שונה במהותו ומקנה זווית שונה לבדיקת החדירות. במאמר זה אתמקד בבדיקה מסוג Gray-Box בסביבות ענן. בבדיקה זו, לבודק יש ידע על המערכת וגישה כלשהי.
הכנות בטרם מתחילים בבדיקה
כשמבצעים בדיקת חדירות בענן, ישנם שיקולים מסוימים שנצטרך לקחת בחשבון על מנת לבצע בדיקה תקנית ואיכותית. בשלב ההכנה לבדיקה על מערכת מבוססת ענן יש לבחון את הסכם רמת השירות (SLA) ומדיניות בדיקות החדירות של ספק הענן. מודל האחריות המשותפת משתנה בין מודל שירות אחד לאחר, ובהתאם לו תחומי האחריות בבדיקות החדירות. אם השירות אותו אנו צורכים ומעוניינים לבדוק הינו מסוג SaaS, יש למקד את הבדיקה רק בשכבות ה-Data וה-Identity. אך אם השירות הינו IaaS, יש להבין שגם שכבת ה-Application וה-OS יכללו בבדיקה. על בסיס מודל האחריות המשותפת המתאים אנחנו יכולים לגזור מה הם האיומים הרלוונטיים לטובת מיקוד הבדיקה, ובנוסף מה באחריותנו כלקוחות באופן כללי. בהמשך לזאת, ספקי ענן מסוימים מצהירים על אחריותם בנושאי אבטחת מידע ובדיקות חדירות במרכיבים וחלקים ספיציפיים מהתשתית שהם מספקים, בזמן שהשאר נכנסים תחת אחריות הלקוח. על מנת לבצע בדיקה תקנית שלא עוברת על מדיניות ספק הענן בנושאים אלו חשוב להבין אותה לעומקה ולתכנן את הבדיקה בהתאם. לאחר ההכנה, נתכנן את הבדיקה על בסיס המידע שאספנו בהכנה, וננסה לשדרג כל שלב בבדיקת החדירות לטובת התאמה טובה יותר.
תכנון, הגדרה וגילוי הבדיקה
בשלב זה, נגדיר את היקף (Scope) הבדיקה בהתאם לפרטים שנאספו. אם יש מרכיבים, חלקים, או שירותים מסוימים בתשתית ספק הענן אשר אסורים לבדיקה, נבהיר זאת בהגדרת ההיקף. בהתאם לזאת נגדיר אילו מרכיבים, חלקים, ושירותים מתשתית הענן הינם חלק מהבדיקה. עוד בשלב התכנון, אם מתבצע Threat Modeling ברמה מסוימת כדאי לקחת בחשבון את איומי הענן המובילים והרלוונטיים למודל הענן שבו שוכנת המערכת המיועדת להבדק. מומלץ בנוסף גם לשאול את ספק הבדיקה על מידת הניסיון שלו עם תשתית הענן הספיציפית, ולבקש דוגמאות לבדיקות מוצלחות.
ביצוע בדיקת חדירות מסוג Gray-Box מתחיל באיסוף מידע וגילוי, כך שגם בשלב ראשוני של הבדיקה ניתן למקסם את התוצאות על ידי חיפוש מידעים הקשורים לענן כגון מפתחות, קישורים, קבצי קונפיגורציה ועוד. בשלב הגילוי כדאי לוודא את ההיקף שהגדרנו בשלב התכנון, ולפענח מהם המרכיבים מתשתית הענן אשר נמצאים באחריותנו ויכולים להתגלות פגיעים (חקירת רשומות DNS עשויה להיות אפילו יעילה מהרגיל). תוצאות הבדיקה מגיעות כדו"ח שמונה את הפגיעויות, פירוטן הטכני וחומרתן. מכיוון שפורמט הדו"ח משתנה מספק לספק ובזאת ארגון המידע מהבדיקה, כדאי לבקש מהספק המבצע את הבדיקה להקדיש חלק ספציפי מהדו"ח למידע הקשור באופן ספיציפי לתשתית הענן. מידע זה יכול לכלול את מרכיבי תשתית הענן שזוהו, מידע שנאסף בשלב הראשוני של הבדיקה, פגיעויות שנמצאו וכו'.
מאת: עוז אבנשטיין, מנכ"ל Avensec
