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

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

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

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

חוקרי F5 Labs סרקו רשימות של ארגונים, שמשאבי הענן שלהם נחשפו מאז 2017 בשל אבטחה לקויה מכוונת. קצב הגידול של התופעה הזאת הגיע ל-200% מ-2017 ל-2018.

עד עתה, ב-2019, עם ממוצע של 2.5 פריצות בחודש, היינו מצפים לראות סך הכל 30 פריצות עד סוף 2019. יחד עם זאת, קצב הגידול בין 2017 ל-2018 מלמד אותנו, שהאומדן שלנו ל-2019 הוא נמוך מידי. אם הגידול של 200% ימשיך, נוכל לצפות לראות 90 פריצות אבטחה בענן ב-2019. גרוע מכך, אנו בטוחים, שהרשימות שלנו מייצגות רק חלק קטן מהארגונים, שנחשפו לתופעה הזאת.

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

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

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

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

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

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

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

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

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

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

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

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

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

מאת: לורי מקויטי, אפריל 2019.
מומחית איומים ראשית ב-F5 Networks