שרשרת האספקה הדיגיטלית של ארגון כבר מזמן לא נגמרת בקווי הייצור, במלאי או בלוגיסטיקה. היא מתחילה במערכות SaaS, עוברת דרך ספקי ענן, חברות פיתוח, שירותי שכר, אינטגרטורים, מוקדי שירות, קבלני משנה, ולעיתים גם דרך הספקים של הספקים. כל חיבור כזה מייצר ערך עסקי, אבל גם פותח מסלול גישה חדש למידע, לתשתיות ולתהליכים קריטיים.
זו בדיוק הסיבה שאבטחת ספקים צד ג' הפכה מנושא של רכש וציות לנושא ליבה של ניהול סיכוני סייבר. ארגונים שכבר מבינים זאת לא מנסים "לסמן וי" על שאלון ספק פעם בשנה. הם בונים שיטה: מיפוי, דירוג, בקרה, חוזים, ניטור ותגובה.
למה ספקים הפכו לנקודת כניסה מועדפת
תוקפים לא תמיד מחפשים את הדלת הראשית. פעמים רבות קל יותר להגיע לארגון דרך שותף חיצוני עם הרשאות, חיבור API, גישת תחזוקה מרחוק או גישה לנתונים. כאשר ספק מחובר למערכות עסקיות, ל-CRM, לתשתית ענן או למערכות כספיות, כל חולשה אצלו עלולה להפוך במהירות לבעיה אצל הלקוח.
הקושי גדל משום שלא כל הספקים נראים "טכנולוגיים" במבט ראשון. גם משרד הנהלת חשבונות, ספק דיוור, חברת תמיכה או מוקד שירות עשויים להחזיק מידע רגיש מאוד. במקרים רבים דווקא הספקים הקטנים, אלה שאינם מפעילים מערך אבטחה בוגר, מחזיקים בגישה רחבה יותר ממה שצריך.
יש כאן גם שכבה נוספת: ספקי משנה. ארגון יכול לבצע בדיקות נאותות לספק ראשי, אך לא תמיד לדעת מי מתחזק בפועל את רכיבי התוכנה, מי מארח את השירות, ואילו ספריות קוד ותוספים מוטמעים במוצר.
לא כל ספק הוא אותו סיכון
הטעות הנפוצה ביותר היא לנהל את כל הספקים באותה שיטה. בפועל, ספק שמנקה משרדים אינו דומה לספק שמתחבר ל-VPN הארגוני, וספק תוכנה שמחזיק נתוני לקוחות אינו דומה ליועץ חיצוני עם גישה למסמכים בודדים.
כדי לעבוד נכון צריך לסווג ספקים לפי השפעה עסקית ואבטחתית. זהו הבסיס לכל תוכנית TPRM, כלומר ניהול סיכוני צד שלישי.
אחרי שמבינים את ההבדלים, קל יותר לקבוע סדרי עדיפויות:
- ספק קריטי: גישה למערכות ליבה, נתוני לקוחות, תשתיות ייצור או הרשאות אדמיניסטרטיביות
- ספק מהותי: גישה מוגבלת למידע רגיש או השפעה על תהליך עסקי חשוב
- ספק תומך: שירות ללא גישה ישירה למידע רגיש
- ספקי תוכנה וענן
- ספקי שירותים מקצועיים
- קבלני משנה עם חיבור מרחוק
- ספקים מזדמנים או נקודתיים
הסיווג הזה צריך להשפיע על עומק הבדיקה, תדירות המעקב, ניסוח החוזה, ודרישות הדיווח במקרה של אירוע.
מה בודקים לפני חתימה על הסכם
בדיקת ספק לא מתחילה בחתימה, אלא הרבה לפני. כבר בשלב הרכש יש לבחון איזה מידע יעבור לספק, אילו הרשאות יידרשו, האם יש חיבור ישיר לרשת, ומהי ההשלכה אם השירות יושבת או ייפרץ.
שאלון אבטחה הוא נקודת פתיחה טובה, אבל הוא לא מספיק לבדו. ארגון בוגר משלב בין שאלון, מסמכי מדיניות, עדויות טכניות, ולעיתים גם בדיקות מעשיות. אם הספק מפתח תוכנה, חשוב לברר כיצד הוא מנהל עדכונים, פגיעויות, קוד פתוח ושרשרת בנייה. אם מדובר בשירות מנוהל, חשוב לבדוק גישת תמיכה, ניהול זהויות, תיעוד פעולות ויכולות תגובה לאירוע.
חשוב גם לבחון עד כמה תוכנית האבטחה של הספק מתאימה לצורכי הארגון. לא כל ספק חייב להחזיק את אותם תקנים, אך הספק צריך להראות יכולת לשמור על סודיות, יושרה וזמינות של המידע ברמה שמתאימה לסיכון.
בדרך כלל נכון לבדוק לפחות את הנושאים הבאים:
- ניהול גישה: MFA, הפרדת תפקידים, הרשאות מינימליות, ניהול משתמשים זמניים
- הגנת תשתיות: הקשחה, ניטור, ניהול חולשות, מדיניות טלאים
- הגנת מידע: הצפנה במעבר ובמנוחה, גיבויים, מחיקה מאובטחת
- תגובה לאירוע: זמני דיווח, צוות אחראי, יכולת תחקור ושחזור
- ציות: עמידה בדרישות רגולציה ותקנים רלוונטיים
- שרשרת משנה: שקיפות לגבי ספקים נוספים ורכיבי תוכנה
מסגרות ותקנים שעוזרים לייצר סדר
אבטחת ספקים אינה תחום פרוץ. יש היום מסגרות עבודה ברורות שמאפשרות לבנות תוכנית עקבית ולא אוסף של בדיקות נקודתיות. ISO/IEC 27001, ובעיקר הנספח העוסק ביחסי ספקים, נותן בסיס מצוין לדרישות חוזיות, ניהול הרשאות ובקרות תפעוליות. ISO/IEC 27036 מתמקד ישירות ביחסי מזמין וספק. NIST SP 800-161 מספק מסגרת חזקה לניהול סיכוני סייבר בשרשרת האספקה. גם ב-NIST CSF יש קטגוריות ייעודיות לנושא.
בארגונים שפועלים מול שווקים בינלאומיים, או כפופים לרגולציה מתקדמת, נושא שרשרת האספקה כבר אינו בגדר המלצה. דרישות כמו NIS2 מחזקות את האחריות של הנהלה ודירקטוריון לראות בספקים חלק אינטגרלי ממערך ההגנה.
הערך האמיתי של התקנים אינו רק בביקורת או באישור. הוא ביכולת ליצור שפה משותפת בין אבטחת מידע, רכש, משפטית, תפעול ו-IT.
| תחום | מה כדאי לדרוש | מתי בודקים |
|---|---|---|
| גישה והרשאות | MFA, PAM, הרשאות מינימליות, חשבונות ייעודיים | לפני חיבור ולאורך ההתקשרות |
| הגנת מידע | הצפנה, סיווג מידע, גיבויים, מדיניות שמירה ומחיקה | לפני חתימה ובביקורת תקופתית |
| פיתוח ותוכנה | ניהול חולשות, עדכונים, SBOM, בדיקות קוד | לפני רכש ובכל עדכון מהותי |
| ניטור ותגובה | לוגים, SIEM, התראות, SLA לדיווח על אירוע | באופן רציף |
| ציות וחוזים | זכות ביקורת, חובת דיווח, תתי-מעבדים, ביטוח | בשלב המו"מ והחידוש |
החוזה הוא כלי אבטחה, לא רק מסמך משפטי
הרבה ארגונים משקיעים בבדיקות טרום התקשרות, אך שוכחים לעגן את הדרישות במסמכים מחייבים. בלי סעיפים ברורים, גם ספק עם רצון טוב עלול לפרש את חובותיו בצורה מצמצמת מדי.
הסכם טוב צריך להגדיר אילו בקרות אבטחה נדרשות, באילו מועדים, ואיך נמדדת עמידה בהן. הוא צריך לכלול חובת דיווח על אירועי אבטחה בפרק זמן מוגדר, זכות ביקורת, חובת שיתוף פעולה בחקירה, והוראות ברורות לסיום התקשרות והחזרת מידע.
זה המקום שבו החיבור בין משפטית, רכש ואבטחת מידע הופך קריטי. שפה חוזית שלא מתייחסת למציאות הטכנית תישאר חלשה. מנגד, דרישות טכניות שאינן מעוגנות בהסכם יתקשו להיאכף.
סעיפים שחוזר לראות בחוזים בוגרים:
- דיווח אירוע: תוך מספר שעות או עד 24 שעות, בהתאם לסיכון
- זכות ביקורת: ביקורת עצמאית, שאלונים, סקירת מסמכים או בדיקה מוסכמת
- שימוש בתתי-ספקים: איסור או חובת אישור מראש
- סיום התקשרות: החזרת מידע, מחיקה מאומתת, נטרול גישות
- רמת שירות: זמני תגובה, טיפול בחולשות, זמינות שירות
הבדיקה לא נגמרת ביום העלייה לאוויר
אחד הפערים הגדולים בניהול ספקים הוא המעבר החד בין שלב הרכש לשלב התפעול. הארגון משקיע מאמץ בחתימה, ואז מניח שהכול בשליטה. בפועל, סיכונים נוצרים דווקא אחרי תחילת העבודה: עדכוני גרסה, שינויי הרשאות, החלפת תשתיות, ספק משנה חדש, או שינוי במודל השירות.
לכן ניטור רציף הוא שכבת חובה. צריך לעקוב אחרי חיבורים פעילים של ספקים, חריגות בגישה, שימוש בהרשאות, חולשות חדשות, ואירועים שיכולים להשפיע על שרשרת האספקה. אם הספק מחובר למערכות מרכזיות, כדאי לשלב את הנתונים הללו ב-SOC ולחבר אותם למערכי SIEM, EDR או XDR.
במקום להסתמך רק על בדיקה שנתית, נכון לקבוע מחזור בקרה דינמי. ספק קריטי ייבדק בתדירות גבוהה יותר, ולעיתים גם יקבל תרגיל משותף של תגובה לאירוע.
זה כולל גם היבט אנושי. צוותי רכש, מנהלי ספקים ומנהלי מערכות צריכים לדעת לזהות סימני אזהרה: בקשה חריגה להרשאות, חיבור חדש ולא מתועד, שינוי בבעלות הספק, ירידה ברמת השירות או סירוב לשקיפות.
טכנולוגיה נכונה מצמצמת שטח חשיפה
אין פתרון יחיד שמגן על שרשרת האספקה, אבל יש שילוב כלים שמקצר את חלון הסיכון באופן משמעותי. סביבת Zero Trust, עם אימות מתמיד והרשאות מדויקות, מתאימה מאוד לעבודה עם צדדים שלישיים. במקום "אמון" שמבוסס על VPN או על היכרות רבת שנים, כל חיבור נבדק לפי זהות, הקשר, מכשיר ורמת סיכון.
מערכות IAM ו-PAM מסייעות לשלוט בגישה של ספקים. הן מאפשרות הקצאת הרשאות זמניות, תיעוד סשנים, נטרול חשבונות רדומים והפרדה בין חשבונות שירות לחשבונות אנושיים. במקביל, ניטור רשת ותחנות קצה עוזר לזהות תנועה חריגה שנובעת מחיבור ספק.
כאשר יש צוות SOC פעיל 24/7, קל יותר לזהות דפוסים חריגים בזמן אמת. שירותי MSSP יכולים לעזור במיוחד לארגונים שאין להם יכולת להפעיל מערך פנימי מלא, משום שהם מחברים בין זיהוי, תחקור ותגובה. כאשר הפיקוח רציף, גם סיכונים שמגיעים מצד שלישי הופכים גלויים יותר ופחות מפתיעים.
שקיפות עם ספקים היא יתרון, לא חולשה
יש ארגונים שחוששים לדרוש יותר מדי מספקים, שמא יכבידו על התהליך העסקי. בפועל, ספקים איכותיים מעריכים לקוחות שמנהלים את הנושא ברצינות. דרישות ברורות מייצרות ציפיות ברורות, ולעיתים גם משפרות את רמת האבטחה של כל הצדדים.
שקיפות אינה אומרת לחשוף הכול. היא אומרת להגדיר מנגנוני דיווח, לשתף התראות רלוונטיות, לבקש מידע על רכיבי תוכנה מהותיים, ובמקרים מסוימים גם לדרוש SBOM. כאשר שני הצדדים יודעים מה מותקן, מי מחובר, אילו רכיבים נמצאים בשימוש ואילו חולשות פתוחות, אפשר לפעול מהר יותר ובדיוק גבוה יותר.
גם תרגולים משותפים הם חלק מהשקיפות הזאת.
ארגון שלא תרגל עם ספק קריטי תרחיש של דליפת מידע, השבתה או פגיעה בחיבור מרחוק, מגלה לעיתים מאוחר מדי שיש פער בין מה שנכתב בחוזה לבין מה שניתן לבצע בפועל.
תוכנית עבודה מעשית ל-90 הימים הקרובים
הדרך לשפר אבטחת ספקים לא חייבת להתחיל בפרויקט ארוך ומורכב. ברוב הארגונים אפשר לייצר שינוי משמעותי בתוך רבעון אחד, אם עובדים בסדר הנכון.
תחילה ממפים. אחר כך מדרגים. לאחר מכן מחברים בין תהליך הרכש, הדרישות החוזיות והבקרה הטכנית. לבסוף בונים שכבת ניטור ותגובה.
אפשר להתחיל כך:
- למפות את כל הספקים עם גישה למידע, למערכות או לרשת.
- לסווג אותם לפי קריטיות עסקית ורמת חשיפה.
- לעדכן שאלון ספקים ולקבוע רף מינימום אחיד ל-MFA, הצפנה ודיווח אירוע.
- להוסיף להסכמים זכות ביקורת, חובת דיווח וסעיפי סיום התקשרות.
- לחבר את הספקים הקריטיים לבקרה רציפה דרך SOC, SIEM או פלטפורמת TPRM.
- לקיים תרגיל תגובה לאירוע עם לפחות ספק אחד מהותי.
ארגונים שפועלים כך מגלים מהר מאוד שאבטחת ספקים אינה מעכבת את העסק. היא דווקא מאפשרת לעבוד עם יותר ביטחון, לבחור שותפים טובים יותר, ולבנות שרשרת אספקה דיגיטלית יציבה, אחראית ומוכנה יותר למה שמגיע.
