גורמי סיכון הניתנים לשינוי הם המנופים שבאמת ניתן להפעיל כדי להפחית סיכונים: חוקי גישה שניתן להדק, פריסות שניתן להגביל, ספקים שניתן להעריך מחדש, והתראות שניתן לכוונן. דוגמה מעשית זו למטריצת בקרת סיכונים נבנתה עבור מובילי מוצר ותפעול ב-SaaS שרוצים דרך קלה לדרג סיכונים, לבחור בקרות ולשמור תיעוד מבלי להפוך את הצוות למומחי ציות.
דוגמה למטריצת בקרת סיכונים (תבנית קלה שניתן להעתיק)
מטריצת בקרת סיכונים היא טבלה המקשרת בין (1) סיכון ספציפי, (2) הבקרה/ות שמפחיתה אותו, (3) מי הבעלים של אותן בקרות, (4) מהו התיעוד המוכיח שהבקרה התקיימה, ו-(5) כיצד מדרגים סיכון אינהרנטי מול סיכון שיורי.
ראיתי צוותים נכשלים מאחת משתי סיבות: המטריצה מופשטת מדי (נקראת כמו מסמך מדיניות) או כבדה מדי (אף אחד לא מעדכן אותה). התבנית להלן היא תפעולית במכוון. היא מניחה שאתם צוות SaaS שמשחרר גרסאות מדי שבוע, משתמש בתשתית ענן ומסתמך על ספקים חיצוניים.
תחום סיכון
הצהרת סיכון
סיכון אינהרנטי (סבירות x השפעה)
בקרות מפתח
סיכון שיורי (סבירות x השפעה)
בעל הבקרה
תיעוד (קל)
תדירות בדיקה
בקרת גישה
חשבון מנהל שנפרץ מוביל לחשיפת נתונים
4 x 5 = 20
SSO + MFA לכל המנהלים; הרשאות מינימליות; סקירת גישה רבעונית
2 x 5 = 10
IT/Ops
ייצוא צילום מסך של רשימת מנהלים + אכיפת MFA; כרטיס סקירת גישה
רבעוני
ניהול שינויים
פריסה לקויה גורמת להשבתה או השחתת נתונים
4 x 4 = 16
סקירות PR; בדיקות CI; פריסה מדורגת; נוהל חזרה לאחור (Rollback)
2 x 4 = 8
מוביל פיתוח
יומני CI + קישורי PR עבור גרסה שנדגמה; תיעוד תרגול חזרה לאחור
דגימה חודשית
תגובה לאירועים
תגובה איטית מגדילה את ההשפעה על הלקוח ואת היקף הפריצה
דירוג ספקים; DPA; סקירת SOC 2; מינימום נתונים משותפים
2 x 5 = 10
אבטחה/משפטי
רשימת דירוג ספקים + תיעוד קבלת דוח SOC 2
שנתי + בעת שינוי
שמירת נתונים
נתונים שנשמרים זמן רב מדי מגדילים את רדיוס הפגיעה והסיכון המשפטי
3 x 4 = 12
מדיניות שמירה; משימות מחיקה אוטומטיות; מגבלות שמירת גיבויים
2 x 4 = 8
הנדסת נתונים
יומני הרצת משימות + צילום מסך של הגדרות מדיניות גיבוי
רבעוני
ניטור
בעיות נשארות ללא זיהוי עד שתלונות לקוחות מגיעות
4 x 4 = 16
SLOs; התראות; שמירת יומנים; זיהוי חריגות
2 x 4 = 8
SRE
צילום מסך של לוח מחוונים SLO + הערות ביקורת התראות
חודשי
אם אתם רוצים "שכבת החלטות" חזקה יותר על גבי זה, שלבו את המטריצה עם מסגרת קבלת החלטות כך שכל שורת סיכון שיורי גבוה תייצר רשימה קצרה של אפשרויות הפחתה שניתן להשוות זו לצד זו. אנו משתמשים בדיוק בתהליך עבודה זה בתוך לוחות ההחלטות של Lucid, והוא מתמפה בצורה נקייה להחלטות צוותיות כמו "הידוק גישת מנהלים עכשיו לעומת אחרי המעבר". אם הצוות שלכם זקוק לרענון בבחירת מסגרות, השתמשו ב-כיצד לבחור מסגרת קבלת החלטות עבור הצוות שלכם.
מהם סיכוני SaaS נפוצים שכדאי לעקוב אחריהם?
סיכוני SaaS נפוצים אינם "קטגוריות ציות". הם מצבי כשל שיוצרים נזק ללקוח: השבתה, חשיפת נתונים, חיוב שגוי או אובדן יכולת ביקורת. התחילו באזורים שבהם שינוי תהליכי קטן מפחית באופן מהותי את ההסתברות או ההשפעה.
הרשימה הקצרה שאני עוקב אחריה עבור צוותי SaaS היא: בקרת גישה, ניהול שינויים, תגובה לאירועים, סיכון ספקים, שמירת נתונים וניטור. ניתן להוסיף עוד בהמשך, אך אלו מכסים את רוב האירועים האמיתיים שראיתי: חשבון שירות עם הרשאות יתר, תיקון דחוף שלא נבדק, התראה שאף אחד לא היה אחראי עליה, אינטגרציה עם ספק ששאבה יותר נתונים מהמתוכנן.
שני כללי היקף מעשיים שומרים על זה קל. ראשית, עקבו אחר סיכונים שבהם ניתן לציין בעלים יחיד ובקרה יחידה שניתן לאמת. שנית, התמקדו בגורמי סיכון הניתנים לשינוי: אם אינכם יכולים לשנות זאת ברבעון, זה לא שייך למטריצת "10 המובילים".
אם אתם זקוקים לאוצר מילים רשמי למה ש"סיכון" ו"בקרה" אומרים, המסגרת של NIST ברורה ושימושית גם למי שאינו מומחה. ה-סקירה של מסגרת ניהול הסיכונים של NIST היא נקודת התייחסות מוצקה להגדרות מבלי לטבוע בניירת.
אילו בקרות מפחיתות את הסיכון השיורי הגבוה ביותר?
סיכון שיורי הוא הסיכון שנותר לאחר הבקרות. כל המטרה של מטריצת בקרת סיכונים היא למצוא את השורות שבהן הסיכון השיורי עדיין גבוה בצורה לא נוחה, ואז להחליט איזה שינוי בבקרה באמת מזיז את המחט.
התחילו בדירוג כל סיכון עם סולם פשוט שצוותים יכולים להשתמש בו בעקביות. אני שומר על זה פשוט: סבירות 1-5, השפעה 1-5, הכפלה לציון 1-25. אם תרצו להשתמש במשהו מורכב יותר בהמשך, תוכלו, אך בפועל העקביות חשובה יותר מהמתמטיקה. אם אתם צריכים להפגין קפדנות, תוכלו לשאול שפה מניתוח תרחישים בסיסי ולהתייחס לסבירות כ"טווח תדירות צפוי" (רבעוני לעומת שנתי) ולהשפעה כ"טווח חומרה גלוי ללקוח".
הנה האופן שבו אני מחליט מה ליישם קודם כאשר הסיכון השיורי גבוה:
גורם סיכון שיורי
בקרה שבדרך כלל מנצחת
למה זה עובד ב-SaaS
יותר מדי חשבונות חזקים
אכיפת SSO + MFA + הרשאות מינימליות
מסיר במהירות סוגים שלמים של סיכוני אישורים וסיכונים פנימיים
פריסות מסוכנות
שערי CI + פריסות מדורגות + תרגולי חזרה לאחור
הופך כשל לא ידוע לכשל מבוקר
תגובה איטית לאירועים
מדרג חומרה ברור + בדיקות התראה
מפחית את זמן הזיהוי וזמן ההפחתה
אי-ודאות לגבי ספקים
דירוג ספקים + מזעור נתונים
מקטין את רדיוס הפגיעה גם אם הספק נכשל
התפשטות נתונים
מחיקה אוטומטית + שמירת גיבויים קצרה יותר
מצמצם את מה שניתן להדליף, לזמן לבית משפט או לנצל לרעה
עייפות מהתראות
בעלות על התראות + ביקורת התראות חודשית
מונע כשלים שקטים ומצבים שבהם "אף אחד לא יודע מה זה אומר"
טיפ שימושי: התייחסו לבחירת בקרות כמו למטריצת השפעה מול מאמץ. אם בקרה היא בעלת השפעה גבוהה ומאמץ נמוך (למשל, "MFA לכל המנהלים"), בצעו זאת מיד. אם היא בעלת השפעה גבוהה אך מאמץ גבוה (למשל, "בידוד סביבה מלא"), צרו אפשרויות עם אבני דרך מדורגות.
כאשר צוותים מתווכחים על בקרות, אל תתווכחו ב-Slack. שימו זאת בלוח החלטות והשוו אפשרויות עם השלכות. Lucid בנויה לכך: אתם מדביקים את הדילמה המורכבת, היא מייצרת מפת אפשרויות עם יתרונות, חסרונות והשלכות עתידיות, ואתם יכולים להשוות בתצוגות רשת/טבלה/מיקוד ככל שהאילוצים משתנים. אם אתם רוצים לראות כיצד צוותי מוצר משתמשים בכלי AI אישיים בתהליכי עבודה אמיתיים, כיצד מנהלי מוצר וצוותי UX משתמשים בעוזר AI אישי מראה את הדפוס.
הפכו שורת סיכון גבוה למפת אפשרויות (דוגמה)
הגדרה: מפת אפשרויות היא השוואה מובנית של נתיבי הפחתה, המציגה יתרונות, חסרונות והשלכות עתידיות כדי שתוכלו לבחור שינוי בבקרה מבלי לנחש.
שורת דוגמה: "חשבון מנהל שנפרץ מוביל לחשיפת נתונים" בעלת סיכון שיורי 10, אך בסיס הלקוחות שלכם עובר לשוק היוקרה וההשפעה עולה בפועל.
מפת אפשרויות שכדאי ליצור:
אפשרות א': אכיפת MFA מבוסס חומרה לתפקידים בעלי הרשאות בלבד.
אפשרות ב': אכיפת MFA לכולם בתוספת חוקי גישה מותנים.
אפשרות ג': פיצול הרשאות מנהל להעלאת הרשאות מוגבלת בזמן עם אישורים.
ב-Lucid, כל אפשרות הופכת לעמודה, עם יתרונות/חסרונות ו"השלכות עתידיות" מצורפות. המפתח הוא שכאשר מערכות משתנות (IdP חדש, חשבונות ענן חדשים, כוח אדם חדש בכוננות), אתם מעדכנים את ההקשר פעם אחת והלוח נשאר עקבי.
כיצד מתעדים ראיות מבלי להאט את הצוותים?
ראיות הן המקום שבו צוותי SaaS או מגזימים (צילומי מסך של הכל) או לא עושים כלום (סמכו עליי, זה מופעל). נקודת האיזון היא פריט תיעוד אמין אחד לכל בקרה שקל לאסוף וקשה לזייף.
הגדרה: ראיות בקרה הן הוכחה קלה לכך שבקרה פעלה במהלך תקופת זמן מסוימת, לא נרטיב לגבי הסיבה לכך שזה חשוב.
כמה דפוסים שעובדים מבלי ליצור בירוקרטיית ציות:
עבור בקרות גישה, ראיות יכולות להיות רשימה מיוצאת של משתמשים בעלי הרשאות, בתוספת תצוגת הגדרות המציגה אכיפת MFA. עבור ניהול שינויים, דגמו גרסה אחת בחודש ואספו את קישור ה-PR, אישור ה-CI ותיעוד הפריסה. עבור תגובה לאירועים, הראיות הן קישור לתחקיר ותוצאת בדיקת התראה. עבור סיכון ספקים, הראיות הן תיעוד קבלת דוח SOC 2, קיום DPA והערה על נתונים משותפים. עבור שמירת נתונים, הראיות הן יומני הרצת משימות והגדרות שמירת גיבויים. עבור ניטור, הראיות הן צילום מסך של לוח מחוונים SLO והערת ביקורת התראות.
זהו גם המקום שבו צוותים נתקעים בגלל "התפשטות תיעוד". שימו קישורי ראיות בתוך המטריצה עצמה, לא במסמך נפרד שאף אחד לא פותח. כשאתם צריכים כתיבה מעמיקה יותר, שמרו עליה מכוונת החלטות. אני אוהב את מבנה ה"למה / מה / הוכחה": למה הסיכון חשוב, איזו בקרה קיימת, הוכחה שהיא פעלה.
אם הצוות שלכם מנסה לתקנן את האופן שבו אתם כותבים מסמכים תפעוליים ולהימנע מכפילות מיושנת, העקרונות ב-מסגרות קבלת החלטות: המדריך המלא מתמפים בצורה מפתיעה לראיות: פורמט עקבי מפחית ויכוחים ומאיץ סקירות.
עבור אימות חיצוני של "איך נראות ראיות טובות", הנחיות SOC 2 הן אמת מידה מעשית גם אם אינכם שואפים אליהן עדיין. הסקירה של Vanta על בקרות SOC 2 וציפיות לראיות היא בדיקת שפיות שימושית עבור פריטי תיעוד קלים ותדירות בדיקה.
כיצד סוקרים ומעדכנים את המטריצה מדי חודש?
סקירה חודשית היא המקום שבו המטריצה הופכת לאמיתית. אם היא לא נסקרת, היא לא מערכת בקרה, היא גיליון אלקטרוני.
הגדרה: סקירת מטריצה חודשית היא פגישה תפעולית קצרה שמעדכנת ציוני סיכון על סמך שינויים במערכות, אנשים, ספקים ולמידה מאירועים.
נהלו זאת כטקס של 30 דקות עם משמעת גבוהה. הסדר חשוב כי הוא מונע התעסקות בטפל.
עדכנו קלטים של "מה השתנה": ספקים חדשים, שירותי ייצור חדשים, תפקידי מנהל חדשים, אירועים מרכזיים, שינויים ארכיטקטוניים גדולים.
דרגו מחדש סיכון אינהרנטי ושיורי רק עבור השורות שהושפעו משינויים אלו.
אשרו שקיימות ראיות לבקרות המיועדות לאותו חודש וציינו פערים.
עבור כל שורה מעל סף הסיכון השיורי שלכם, צרו החלטת הפחתה אחת עם 2-3 אפשרויות והקצו בעלים ותאריך יעד.
זה הכל. ללא ויכוחי מדיניות. ללא "אנחנו צריכים". אתם או מתאימים את המטריצה או יוצרים החלטת אפשרות כדי להתאים אותה.
כאן Lucid משתלבת באופן טבעי: פריטי הסיכון השיורי הגבוה של כל חודש הופכים ללוחות החלטות. אתם יכולים לשמור את המטריצה כאינדקס, ואת הלוחות כתיעוד החלטות. כאשר ההקשר משתנה בחודש הבא, אתם מעדכנים את קלטי הלוח והיתרונות/חסרונות וההשלכות נשארים קוהרנטיים. אם אתם רוצים ליישם תהליך עבודה זה במהירות, התחילו עם פיילוט קטן: בחרו שתי שורות סיכון גבוה והריצו את התהליך למשך חודש אחד, ואז הרחיבו.
בדיקת בקרות ודירוג סיכונים שלא ישקרו לכם
בדיקת בקרות נשמעת כבדה, אך בדיקה קלה היא פשוט אימות שהבקרה עדיין עובדת. המטרה היא לתפוס סחיפה: הדעיכה האיטית של הגדרות, בעלות והרגלים.
הנה מה שמצאתי ששומר על דירוג כנה:
השתמשו במדרג דירוג יחיד בין צוותים. אם אתם צריכים להגן על הציון, כתבו משפט אחד של רציונל במטריצה. אם אתם משנים ציון, ציינו מה השתנה (דרגת לקוח חדשה, סוג נתונים חדש, אירוע חדש). אם אתם רוצים להפחית ויכוחים, השתמשו בגישת "מטריצת קבלת החלטות" עבור שורות שנויות במחלוקת: הגדירו קריטריונים (השפעה על לקוח, חשיפה רגולטורית, עלות תפעולית), שקללו אותם, ודרגו אפשרויות. אתם לא צריכים כלי מחשבון מטריצה כדי לעשות זאת; אתם צריכים עקביות ובעלים ברור.
הימנעו מדיוק שווא. 16 לעומת 15 אינו משמעותי. שינוי דרגה הוא משמעותי: נמוך (1-6), בינוני (7-12), גבוה (13-25). אם הצוות שלכם רוצה שפה סטטיסטית, שמרו עליה מבוססת: "טווח סבירות" מספיק. שמרו "ניתוח הגדרת שונות" למקרים שבהם אתם באמת מנתחים תדירות אירועים בין שירותים.
שאלות נפוצות
מהן דוגמאות למדדי סיכון עבור צוותי SaaS?
מדדי סיכון הם אותות מדידים לכך שסיכון גובר, כמו עלייה במספר החשבונות בעלי ההרשאות, עלייה בשיעור כשל בשינויים, או החמצות התראה חוזרות. בחרו מדדים שניתן לעקוב אחריהם מדי חודש ושמתמפים לבקרה ספציפית שניתן להתאים.
אילו בקרות בדרך כלל מפחיתות סיכון שיורי הכי מהר?
SSO עם MFA לתפקידים בעלי הרשאות, ניקוי הרשאות מינימליות, שערי CI, פריסות מדורגות ומדרג חומרה ברור לאירועים בדרך כלל מייצרים את ההפחתה הגדולה ביותר ליחידת מאמץ. הם חותכים ישירות את הסבירות או מפחיתים את זמן ההפחתה.
האם אנחנו צריכים תרשים זרימה מלא לקבלת החלטות עבור תגובה לאירועים?
אתם צריכים מדרג חומרה פשוט ונתיב הסלמה, לא תרשים זרימה בגודל קיר. אם אנשים מהססים במהלך אירוע, ה"מי מחליט מה" שלכם לא ברור, לא התרשים שלכם.
מהם היתרונות והחסרונות של AI לניתוח סיכונים?
היתרונות והחסרונות של AI אמיתיים: הוא יכול לנסח מרשם סיכונים ראשוני ולהציע הפחתות במהירות, אך הוא יכול גם להזות בקרות או לפספס את אילוצי המערכת האמיתיים שלכם. השתמשו ב-AI כדי לייצר אפשרויות, ואז אשרו עם בעלים וראיות אמיתיות.
הצעד הבא: בנו את המטריצה הראשונה שלכם ב-45 דקות
פתחו גיליון וצרו שש שורות: בקרת גישה, ניהול שינויים, תגובה לאירועים, סיכון ספקים, שמירת נתונים, ניטור. דרגו כל שורה במהירות, ואז כתבו בקרה אחת ופריט ראיות אחד לכל שורה. המטרה שלכם אינה שלמות, אלא מערכת עובדת שתוכלו לסקור בחודש הבא.
אם אתם רוצים את שכבת "מפת האפשרויות" שעוזרת לכם לבחור הפחתות עם יתרונות/חסרונות והשלכות ברורות שמתעדכנות ככל שהמחסנית שלכם משתנה, צרו לוח החלטות Lucid עבור שני הסיכונים השיוריים המובילים שלכם ושמרו את הקישורים בחזרה במטריצה שלכם. התחילו עם פיילוט קטן, ואז הרחיבו. השתמשו ב-רישום ל-Lucid כדי להתחיל לוח החלטות והפכו את ויכוח הסיכון הבא להחלטה מובנית שאתם באמת יכולים לשחרר.
דוגמה למטריצת בקרת סיכונים עבור צוותי SaaS | Lucid
