הבעיה אינה שהספק לא אמין. הבעיה היא שהגישה שלו חזקה מדי
ארגונים אוהבים לדבר על אמון. תוקפים אוהבים לנצל אמון. ההבדל ביניהם הוא שתוקף לא צריך לשכנע את חומת האש שהוא האקר. הוא צריך להתחבר דרך נתיב שכבר אישרתם. ספק IT עם כלי תמיכה מרחוק, משרד הנהלת חשבונות עם גישה לתיקיית כספים, חברת פיתוח עם מפתח API, יועץ אבטחה עם חשבון אורח בענן, חברת מצלמות עם גישה לרשת פנימית. כל אלה נשמעים הגיוניים. כולם גם יכולים להפוך לדלת פתוחה.
הטעות היא להתייחס לספק כאל ישות אחת. בפועל, ספק הוא אנשים, מחשבים, סיסמאות, תיבות מייל, מערכות פנימיות, קבלני משנה, כלי ניהול, תהליכי עזיבה וטעויות אנוש. גם אם הספק מקצועי, אין לכם שליטה מלאה על מה שקורה אצלו. לכן השאלה הנכונה אינה האם הספק אמין, אלא מה יקרה אם הספק נפרץ היום בבוקר.
שלוש טעויות שחוזרות כמעט בכל ארגון
גישה קבועה במקום גישה לפי צורך
ספק סיים פרויקט, אבל החשבון שלו נשאר פעיל. איש תמיכה נכנס פעם בחודש, אבל ההרשאה שלו פתוחה כל הזמן. יועץ צריך לקרוא דוח אחד, אבל יש לו גישה לתיקייה שלמה. זו לא נוחות. זו התחייבות סיכון פתוחה. כתבנו על זה בהקשר של הרשאות מנהל קבועות, והעיקרון זהה גם לצד שלישי: הרשאה שלא מוגבלת בזמן הופכת בסוף לנכס של התוקף.
חשבון כללי במקום זהות אישית
החשבון support או vendor נראה נוח עד שמנסים להבין מי התחבר, מאיפה, למה ומתי. חשבון משותף מוחק אחריות. הוא גם מקשה מאוד על חקירה אחרי אירוע. לכל אדם חיצוני צריכה להיות זהות אישית, עם אימות חזק, בעלים עסקי, תוקף הרשאה ותיעוד. אין זהות אישית, אין גישה.
לוגים בלי מי שמסתכל עליהם
ארגונים רבים מחזיקים לוגים, אבל לא מחזיקים יכולת פעולה. אם ספק התחבר מחוץ לשעות העבודה, הוריד כמות חריגה של קבצים, ניסה להיכנס למערכת שאינה קשורה אליו או שינה הרשאות, מישהו צריך לדעת את זה בזמן. כאן שירות SIEM SOC מפסיק להיות מוצר טכני והופך לבקרת סיכון עסקית.
מיפוי ספקים הוא לא טבלה. הוא צילום רנטגן של הארגון
NIST SP 800 161 מתייחס לניהול סיכוני שרשרת אספקה כתהליך שצריך להשתלב בניהול הסיכונים הארגוני, ולא להישאר בעולם הרכש בלבד. זו נקודה קריטית. אם אתם לא יודעים אילו ספקים נוגעים באילו מערכות, אילו הרשאות יש להם, מי אישר אותן ומתי הן פוקעות, אתם לא מנהלים אבטחת ספקים. אתם מנהלים תקווה.
מיפוי אמיתי כולל לפחות ארבע שכבות: ספקים שיש להם גישה ישירה לרשת, ספקים שיש להם גישה לענן, ספקים שמחזיקים מידע רגיש מחוץ לארגון וספקים שמתחברים דרך כלי תמיכה או אוטומציה. לכל שכבה כזו צריך בעלים, מדיניות, ניטור ותהליך סיום גישה.
כך נראה מסלול תקיפה דרך ספק
תוקף פורץ לתיבת מייל של עובד אצל ספק שירותים. הוא מוצא התכתבויות עם לקוחות, מזהה ארגון שיש לו פורטל תמיכה, ומאתר קישור ישן להתחברות. הספק עדיין מוגדר כמשתמש חיצוני. אין אימות חזק. אין הגבלה למדינות. אין תוקף הרשאה. התוקף נכנס, מוריד קבצים, מחפש סיסמאות במסמכים, עובר לתיקיית כספים ומייצר נזק שנראה תחילה כמו פעילות רגילה.
בגרסה אחרת, התוקף לא צריך אפילו מייל. הוא קונה ברשת פרטי גישה שדלפו, מחפש שם דומיין של חברה מוכרת, ומנסה אותם בפורטלים של לקוחות. זו בדיוק הסיבה ששירות מודיעין סייבר אינו מותרות. חשיפות זהות של ספקים, עובדים וקבלנים צריכות להדליק נורה לפני שהן הופכות לכניסה בפועל.
החלטות שמקטינות את הסיכון כבר עכשיו
- מנו בעלים לכל ספק. לא איש קשר כללי, אלא בעלים עסקי שאחראי לאישור, הארכה וסיום גישה.
- הפרידו בין גישה למידע לבין גישה לניהול. ספק שצריך לקרוא קובץ לא צריך הרשאת ניהול. ספק שמטפל במערכת אחת לא צריך לראות את שאר הרשת.
- הפעילו אימות חזק לכל גישה חיצונית. MFA הוא בסיס, אבל במקומות רגישים עדיף אימות עמיד יותר בפני דיוג ומדיניות כניסה לפי סיכון.
- הגבילו גישה לפי זמן, מיקום ומכשיר. ספק לא צריך להתחבר מכל מדינה, מכל מחשב ובכל שעה.
- אסרו חשבונות משותפים. כל פעולה צריכה להיות משויכת לאדם ברור. זה תנאי לניהול, לחקירה ולאחריות.
- חסמו כלים לא מאושרים לתמיכה מרחוק. כלי שליטה מרחוק הם כוח. כוח כזה חייב רשימה מאושרת, בקרה וניטור.
- חברו לוגים לתגובה. כניסות ספקים, שינויי הרשאה, הורדות חריגות, יצירת חשבונות חדשים ושימוש בכלי ניהול חייבים להגיע לניטור פעיל.
- סגרו גישה בסוף פרויקט. סוף התקשרות הוא אירוע אבטחה. לא מטלה אדמיניסטרטיבית.
הרחבנו על הסיכון של נתיבי כניסה חיצוניים במאמר על חיבור מרחוק, ועל הסיכון של חשבונות חיצוניים בענן במאמר על משתמשי אורח ב Microsoft 365. שתי הזירות האלה נפגשות בדיוק כאן: ספקים לא נכנסים דרך דלת אחת. הם נכנסים דרך כל מקום שבו נתתם להם לעבוד.
שאלות שחייבות להופיע לפני שנותנים לספק גישה
לפני שמאשרים חיבור חדש, שאלו שאלות קשות. לא בשביל להקשות על העסק, אלא בשביל לא לתת לסיכון להתחפש לשירות.
- לאיזו מערכת הספק צריך לגשת בפועל, ומה אסור לו לראות.
- מי בצד הספק משתמש בגישה, והאם כל משתמש מזוהה אישית.
- האם הגישה מוגבלת בזמן או שהיא נשארת פתוחה עד שמישהו ייזכר.
- האם מופעל אימות חזק והאם הגישה מוגבלת למכשירים מאושרים.
- אילו פעולות של הספק נרשמות בלוגים ומי מקבל התרעה.
- מה תהליך הביטול כאשר עובד אצל הספק עוזב.
- מה הספק מחויב לדווח לכם במקרה של חשד לאירוע אצלו.
- האם יש דרך לשחזר מידע, הרשאות ותצורות אם הגישה נוצלה לרעה.
אבטחת ספקים בלי DLP היא חצי עבודה
גם כאשר הגישה מוגדרת נכון, מידע עדיין יכול לצאת. קובץ לקוחות שנשלח לספק, תיקיית חוזים ששיתפו החוצה, דוח כספי שנפתח בענן, צילום מסך שנשמר במחשב לא מנוהל. לכן מניעת דלף מידע DLP חייבת להיות חלק מהסיפור. לא כל ספק צריך להוריד מידע. לא כל קובץ רגיש צריך לצאת מהארגון. ולא כל שיתוף צריך להיות מותר רק כי מישהו לחץ אישור.
עקרונות שרשרת האספקה של NCSC מדגישים שליטה, בדיקה ושיפור מתמשך. זו בדיוק הגישה הנכונה. לא בודקים ספק פעם אחת ונרדמים. בודקים שוב, מקטינים הרשאות, משנים מדיניות לפי סיכון, ומוודאים שההגנות עובדות גם כשאנשים עסוקים.
מה אנחנו ב-010 בודקים כשאנחנו מסתכלים על גישת ספקים
כשאנחנו ב 010 בוחנים סיכוני צד שלישי, אנחנו לא מסתפקים ברשימת ספקים. אנחנו מחפשים מסלולי כניסה. מי יכול להתחבר. דרך מה. מאיזה מכשיר. עם איזו זהות. לאילו מערכות. תחת אילו הרשאות. עם איזה תיעוד. ואיך מבטלים את הכול אם צריך.
זה מתחיל ב סקר סיכונים שממפה חשיפות, הרשאות, גישות מרחוק ותהליכי עבודה. משם מחברים שכבות הגנה רלוונטיות: מודיעין סייבר לזיהוי חשיפות, SIEM SOC לניטור חריגות, DLP לצמצום דלף מידע, הגנה לעמדות קצה, ובמקומות שבהם יש חשש לכופרה גם הגנה אקטיבית מכופר. לא מוכרים אוסף כלים. בונים שליטה.
צ׳קליסט לאבטחת ספקים
- הוציאו רשימה של כל הספקים עם גישה למערכות, לענן, למידע או לכלי תמיכה.
- סמנו מי מהם מחזיק הרשאה רגישה, גישה קבועה או חשבון ללא בעלים ברור.
- בטלו חשבונות משותפים והחליפו אותם בזהויות אישיות.
- הפעילו MFA לכל ספק, ללא חריגים שקטים.
- הגדירו תאריך תפוגה לכל גישה חיצונית.
- צמצמו הרשאות לפי מערכת, פרויקט וצורך עסקי.
- חברו אירועי כניסה ושינויי הרשאה לניטור פעיל.
- בדקו האם מידע רגיש יכול לצאת לספק ללא בקרה.
- הוסיפו לחוזים חובת דיווח מהירה על אירוע אבטחה אצל הספק.
- קיימו תרגיל קצר: מה עושים אם מחר בבוקר ספק מרכזי מודיע שנפרץ.
השורה התחתונה
אבטחת ספקים אינה נגד ספקים. היא בעד העסק. ספק טוב לא אמור להיפגע מבקרה טובה, אלא לעבוד דרכה. ארגון בוגר לא שואל רק האם יש לנו ספק אמין. הוא שואל האם יש לנו דרך להגביל אותו, לראות אותו, לעצור אותו ולנתק אותו כאשר המציאות משתנה.
הספק שלכם יכול להיות שותף מצוין. אבל מבחינת אבטחה, כל גישה חיצונית היא דלת. דלת שלא יודעים מי פתח, מתי פתח ולמה היא עדיין פתוחה, היא לא דלת עסקית. היא הזמנה.
