אבטחת ענן לדירקטוריונים שעדיין רוצים פירוט הנדסי

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

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

שאלת הדירקטוריון שמסתירה שלוש שאלות הנדסיות

כשדירקטוריון שואל "אנחנו מאובטחים בענן?" הוא בדרך כלל מתכוון לאחד משלושה דברים, והתשובה הנכונה תלויה באיזה:

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

2. האם טעות אחת יכולה להפיל אותנו? זו שאלת ה-blast radius. התשובה ההנדסית היא האם המערכות שלכם בעלות ההשפעה הגבוהה ביותר חולקות גורל עם משהו אחר: אותו account, אותה רשת, אותו ספק זהויות, אותו key vault, אותו pipeline של CI/CD. ההסתברות לטעות היא לא הסוגיה. השאלה היא האם טעות אחת מובילה לאירוע שאפשר להתאושש ממנו או לאירוע קיומי.

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

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

למה תוכניות אבטחת ענן באופן עקבי לא מספקות

לרוב תוכניות אבטחת הענן שאנחנו מבקרים יש את אותה צורה: כלי CSPM (cloud security posture management), זרם SIEM cloud-native, מחזור IAM review, ורשימת בקרות תאימות הממופה לפריימוורק העדכני. זה לא לא נכון. זה פשוט לא שלם בדרכים צפויות.

ממצאי posture מטביעים את הסיגנל. סריקת CSPM טיפוסית על cloud estate בינוני מייצרת 8,000 עד 40,000 ממצאים בריצה הראשונה. ה-funnel של ה-remediation מוגבל על-ידי צוותי ההנדסה שיש להם בעלות על המשאבים, ו-60–80% מהממצאים מקובלים או נדחים לתמיד. התוכנית מבזבזת את רוב האנרגיה שלה על תהליך triage שאף פעם לא סוגר את הפער. גרוע מזה, הצוות מאבד רגישות: misconfiguration אמיתי בפרודקשן מקבל את אותו צבע כמו 2,400 ממצאים אינפורמטיביים לגבי תגיות ברירת מחדל, ובסטטיסטיקה ה-on-call יתעלם משניהם.

זהויות מטופלות כפריט היגיינה במקום כ-control plane. בענן בוגר, זהות היא הפרימטר. תנועה לטראלית אחרי קומפרומיז תלויה כמעט לחלוטין במה שלזהות שנפרצה (אדם או workload) הותר לעשות. לרוב התוכניות יש identity review רבעוני, רשימה של חשבונות broken-glass, ו-SSO. למעטות יש תשובה תוכניתית לשאלה: אילו זהויות יכולות לקרוא נתוני פרודקשן עכשיו, אילו יכולות לכתוב ל-bucket קריטי, ואילו יכולות לעבור role assumption ל-account אחר?

טלמטריית workload היא בקרה חסרה. Configuration זה מה שתוקף מנצל כדי להיכנס. התנהגות workload זה מה שמספר לכם שהוא בפנים. אם משטח הזיהוי שלכם בנוי רק מסריקות תצורה ולוגי audit, אתם משגיחים על הדלתות אבל לא על החדרים. כל תוכנית אבטחת ענן בוגרת שאנחנו מנהלים בסוף מוסיפה runtime workload protection (eBPF, agentless instance scanning, או שניהם), ואלה שלא, בדרך כלל מגלות את זה בדרך הקשה אחרי אירוע.

ארבע ההשקעות שמזיזות את העקומה

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

1. מפת נתונים אמיתית

לא הרחבה ל-CMDB, לא ספירת ממצאים של CSPM. מפה חיה של: אילו דאטהסטים קיימים, באיזה class רגולטורי הם נכנסים, אילו workloads קוראים או כותבים אליהם, אילו נתיבי גישה קיימים (IAM, רשת, data-plane API), ואיך נראים לוגי ה-egress לכל אחד. בנו את זה עם כל כלי שמתאים ל-stack שלכם (מוצרי DSPM עוזרים, אבל גרף מסודר מ-terraform state יחד עם IAM Access Analyzer ו-VPC flow logs נותן 70% מהערך). בלי זה, כל שיחה על סיכון נתונים היא תיאורטית.

2. בידוד שכבתי קשיח ל-workloads של תכשיטי הכתר

מספר קטן של מערכות מייצגות את רוב פוטנציאל ההפסד אם הן נופלות או מדליפות. זהו את 5–10 העליונים לפי חשיפת הכנסות, חשיפה רגולטורית, או שניהם. אז ודאו שהמערכות האלה לא חולקות גורל עם שום דבר מחוץ ל-tier שלהן: cloud accounts נפרדים, key material נפרד, גבולות זהות נפרדים, נתיבי CI/CD release נפרדים. זו ההשקעה ההנדסית עם המינוף הגבוה ביותר באבטחת ענן והאחת שהכי באופן עקבי מדלגים עליה כי לא נוח לבצע refactor.

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

השאלה "מה התוקף יכול לעשות אם הוא יפרוץ את X?" ניתנת למענה כ-graph traversal. יש כלים (מוצרי CIEM, מקבילי BloodHound-for-cloud, או כלי קוד פתוח בסגנון pacu/cloudgoat) שמחשבים את ה-reachability set מ-principal התחלתי דרך IAM, שרשרות role assumption, ו-resource policies. הריצו את זה שבועית. הפלט הוא רשימת שינויי הזהות בעדיפות שיכווצו את ה-blast radius שלכם הכי הרבה. השקיעו על אלה, לא על 80% התחתונים של ממצאי CSPM.

4. זמני זיהוי ותגובה מדודים

בחרו שלושה ארכיטיפים מתקבלים על הדעת של אירוע ענן (credential חשוף, bucket מוגדר ציבורי בטעות, workload זדוני). הריצו תרגילים לא מתואמים מראש כנגד כל אחד, עם שעון. מדדו: זמן לזיהוי, זמן ל-triage, זמן להכלה. חזרו רבעונית. המספרים עצמם פחות חשובים מהמגמה. אם המגמה שטוחה או מתדרדרת, ההשקעה שלכם ב-detection לא מתממשת בפועל איפה שאתם חושבים.

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

מה דירקטוריונים בעצם צריכים לשאול

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

• איפה הנתונים הכי רגישים שלנו, ואפשר להפיק מפה תוך שעה? התשובה או היעדרה אומרים אם התוכנית באמת תפעולית.
• מה ה-blast radius של שלוש ה-workloads הראשונים שלנו אם הם נפרצו? התשובה צריכה להיות ספציפית, לא "מוגבל מתוקף תכנון".
• מה זמן הזיהוי וזמן ההכלה המדודים שלנו לדליפת credential ברגע זה? מספר מדוד, לא יעד SLA.
• אילו שלוש החלטות הנדסיות אנחנו לוקחים השנה ספציפית כדי להוריד סיכון ענן? אם התשובות כולן על פריסת כלים, התוכנית בשלב קנייה, לא בשלב הפעלה.

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

איפה אנחנו נכנסים

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

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