לא רק לבדוק ספק לפני החוזה: מה מלמד NIST SP 800-161 Rev. 1 על ניהול סיכוני צד שלישי

התקשרות עם ספק טכנולוגי אינה רק החלטת רכש. כל מוצר, שירות SaaS, רכיב תוכנה או ספק חיצוני יכול להכניס לארגון תלות, חולשה או רמת סיכון שלא תמיד נמצאת בשליטתו הישירה.
NIST SP 800-161 Rev. 1 נועד בדיוק למצבים האלה: לעזור לארגונים לזהות, להעריך ולנהל סיכוני סייבר לאורך שרשרת המוצרים והשירותים שהם רוכשים ומשתמשים בהם.

מהו NIST SP 800-161 Rev. 1?

שמו המלא של המסמך הוא:

Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

הגרסה המקורית של SP 800-161 פורסמה ב-2015 והתמקדה בעיקר במערכות מידע פדרליות. Revision 1, שפורסם במאי 2022 ועודכן בנובמבר 2024, הרחיב את המסגרת וממקם Cybersecurity Supply Chain Risk Management, או C-SCRM, כחלק אינטגרלי מניהול הסיכונים הארגוני.

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

למה בכלל צריך C-SCRM?

הבעיה המרכזית היא חוסר שליטה וחוסר נראות.

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

NIST מצביע על סיכונים כגון:

• רכיבים או מוצרים בעלי פונקציונליות זדונית
• מוצרים מזויפים
• חולשות שנובעות מתהליכי פיתוח או ייצור לא מספקים
• חוסר שקיפות לגבי האופן שבו טכנולוגיה פותחה ושולבה
• תלות בספקים ובשכבות נוספות של ספקים
• ירידה ברמת ה־Security, Resilience, Reliability או Integrity של מוצר או שירות

כלומר, גם אם הארגון עצמו פועל נכון, הסיכון יכול להגיע מבחוץ.

זה לא רק “שרשרת אספקה” במובן התעשייתי

המונח Supply Chain עלול להטעות.

SP 800-161 עוסק בעיקר בעולם Information and Communications Technology – ICT, ולכן הוא רלוונטי לא רק ליצרנים או לחברות תעשייתיות.

הוא רלוונטי גם כאשר ארגון רוכש:

• מערכת SaaS
• שירות Cloud
• אפליקציה ארגונית
• מוצר אבטחה
• שירות IT מנוהל
• רכיב תוכנה
• פתרון תקשורת
• מערכת ERP או CRM
• או שירות טכנולוגי אחר שהארגון תלוי בו

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

מידע נוסף במאמר Third-Party Risk Management: ניהול סיכון של ספקים צד שלישי.

מה NIST ממליץ לארגונים לעשות?

אחת הנקודות המרכזיות ב-SP 800-161 Rev. 1 היא שלא מספיק לבצע בדיקה נקודתית.

C-SCRM צריך להיות חלק ממערכת ניהול הסיכונים הארגונית.

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

בפועל, ארגון צריך לדעת:

1. מהם המוצרים והשירותים הקריטיים?
2. מי הספקים המרכזיים?
3. אילו תלויות קיימות?
4. מה הסיכון אם ספק נפגע?
5. איזה מידע עובר אליו?
6. מהן דרישות האבטחה?
7. מי אחראי על הבדיקה?
8. איך מתבצע Monitoring לאחר שההתקשרות התחילה?

Due Diligence הוא רק שלב אחד

כאן חשוב לחבר בין SP 800-161 לבין NIST SP 1326.

• SP 800-161 הוא המסגרת הרחבה.
• SP 1326, שפורסם ביולי 2026, הוא מדריך Quick-Start ממוקד יותר לביצוע Due Diligence על ספקי ICT לפני רכישה או במסגרת בחינה מחדש של ספקים קיימים.

אפשר לחשוב על זה כך:

• SP 800-161 = איך מנהלים C-SCRM ברמת הארגון.
• SP 1326 = איך מבצעים Due Diligence ממוקד על ספק או מוצר.

זו הבחנה חשובה, כי Vendor Assessment חד־פעמי אינו תחליף לתהליך ניהול ספקים לאורך זמן.

קישור פנימי מומלץ: מאמר NIST SP 1326: כך מבצעים Due Diligence לספקי טכנולוגיה לפני ההתקשרות.

מ-Due Diligence ל-TPRM

עבור ארגונים רבים, הדרך הפרקטית ליישם חלק מהעקרונות של SP 800-161 היא באמצעות Third-Party Risk Management – TPRM.

TPRM יכול לכלול:

• Discovery – מיפוי ספקים.
• Classification – סיווג לפי קריטיות וסיכון.
• Due Diligence – בדיקה לפני התקשרות.
• Security Questionnaire – קבלת מידע מובנה מהספק.
• Contracting – הכנסת דרישות להסכם.
• Monitoring – מעקב שוטף.
• Incident Management – טיפול באירוע אצל הספק.
• Offboarding – סיום גישה והסדרת מידע.

SP 800-161 מספק את ההיגיון והמסגרת הרחבה – TPRM הופך אותה לתהליך תפעולי.

מידע נוסף על:

• ניהול סיכונים של ספקים צד שלישי
• ניהול סיכונים בשרשרת אספקה

שאלון ספקים אינו מספיק

גם כאן SP 800-161 מחזק עיקרון חשוב.

שאלון אבטחת מידע יכול לסייע, אבל הוא אינו נותן לבדו תמונה מלאה.

הארגון צריך להבין גם:

• מי הספק?
• איך המוצר פותח?
• מהן התלויות שלו?
• מי הספקים שמאחוריו?
• מהי רמת החוסן שלו?
• מה קורה אם הוא מפסיק לפעול?
• ומה קורה כאשר המוצר משתנה לאורך הזמן?

לכן Security Questionnaire הוא כלי בתוך תהליך, ולא הוכחה לכך שהסיכון נוהל.

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

גם הנהלה צריכה להיות חלק מהתמונה

C-SCRM אינו תהליך ששייך רק לצוות אבטחת המידע.

כאשר ספק קריטי נכשל, ההשפעה יכולה להיות עסקית.

לדוגמה:

• מערכת כספים אינה זמינה
• CRM מושבת
• ספק Cloud נפגע
• מערכת HR מפסיקה לעבוד
• או ספק SaaS מודיע שמידע של הארגון נחשף.

במקרים כאלה נדרשות החלטות של הנהלה, Procurement, IT, Legal, Privacy ו־Business Owners.

לכן SP 800-161 מדגיש גישה רב־שכבתית ומשלב את C-SCRM בתוך תהליכי Risk Management רחבים יותר.

Incident Response חייב לכלול גם ספקים

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

• מה עושים אם ספק SaaS מודיע על Breach?
• האם החשבונות שלנו הושפעו?
• האם יש צורך לבטל Tokens?
• האם צריך לעדכן לקוחות?
• מה חובת הדיווח?
• מי מתקשר עם הספק?
• ומה קורה אם השירות עצמו אינו זמין?

לכן ספקים קריטיים צריכים להיכלל גם ב-Incident Response Plan ובתרגילי Tabletop.

מידע נוסף:

• תרגיל שולחן סייבר: הדרך לבדוק את תוכנית החירום לפני אירוע אמיתי.
• Incident Response – האם הארגון שלכם מוכן לאירוע סייבר השנה?

ומה לגבי ספקי משנה? 4th Party Risks

אחד האתגרים הגדולים הוא שהספק שלנו אינו בהכרח סוף השרשרת.

ספק SaaS יכול להסתמך על:

• Cloud Provider
• Authentication Service
• Payment Provider
• שירות Analytics
• AI Provider
• ספקי Support נוספים

לכן חשוב להבין לפחות את התלויות המהותיות.

NIST עצמו מדגיש שהסיכון יכול להיות קיים גם ברכיבים של מוצר מוגמר ובמסלול שעברו אותם רכיבים לפני שהגיעו לארגון.

זהו גם המקום שבו Fourth-Party Risk הופך לרלוונטי.

החיבור ל-BCP ול-Resilience

Third-Party Risk אינו רק סיכון של Confidentiality. לעיתים הסיכון הגדול ביותר הוא Availability.

• אם ספק קריטי מושבת ל־24 שעות, האם העסק ממשיך לפעול?
• אם הוא נסגר לחלוטין, האם ניתן להעביר את המידע?
• אם שירות Cloud נפגע, האם קיימת חלופה?

לכן SP 800-161 שם דגש גם על Resilience, Reliability ו-Quality של המוצרים והשירותים שהארגון מסתמך עליהם.

זה מחבר את C-SCRM ישירות ל-BCP ול-Business Continuity.

ומה הקשר לתקנה 15 לתקנות הגנת הפרטיות בישראל?

SP 800-161 הוא מסמך NIST ואינו דרישה רגולטורית ישראלית.

עם זאת, קיימת זיקה מקצועית ברורה.

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

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

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

7 שאלות שכדאי לארגון לשאול בעקבות SP 800-161

1. האם אנחנו יודעים מי הספקים הטכנולוגיים הקריטיים שלנו?
2. האם הם מסווגים לפי רמת סיכון?
3. האם מתבצע Due Diligence לפני התקשרות?
4. האם חוזים כוללים דרישות אבטחה ו־Incident Notification?
5. האם אנו מבינים תלויות בספקים נוספים?
6. האם הספקים נבדקים מחדש לאורך זמן?
7. האם תרחיש של פגיעה בספק נכלל ב-Incident Response וב-BCP?

אם חלק מהתשובות אינן ברורות, זו אינדיקציה לכך שתהליך C-SCRM עדיין אינו שלם.

ממסמך NIST לתהליך ארגוני

הערך של SP 800-161 Rev. 1 אינו בכך שהוא מוסיף עוד רשימת דרישות.

הוא מציע תפיסה:

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

זה אומר לחבר בין:

• Procurement
• Security
• Risk
• Legal
• Privacy
• Business Continuity
• Incident Respons
• היחידה העסקית

כאשר התהליך עובד נכון, הארגון אינו שואל רק:

“האם הספק עבר שאלון אבטחה?”

אלא:

“האם אנחנו מבינים ומנהלים את הסיכון שהוא יוצר עבורנו לאורך זמן?”

כיצד אינפוגארד יכולה לעזור?

אינפוגארד מסייעת לארגונים לבנות ולשפר תהליכי Third-Party Risk Management ו-C-SCRM, לרבות מיפוי וסיווג ספקים, Due Diligence, שאלוני אבטחת מידע, Vendor Assessments, בחינת דרישות חוזיות, Monitoring ותהליכי Incident Response מול ספקים.

ניתן לבסס את התהליך על עקרונות NIST SP 800-161 Rev. 1 ולחבר אותו גם ל-SP 1326, תקנה 15, BCP וסקר הסיכונים הארגוני.

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

הארגון שלכם צריך ניהול סיכוני סייבר הנובעים מספקים.

NIST SP 800-161 Rev. 1 מספק מסגרת רחבה לניהול סיכוני סייבר הנובעים מספקים, מוצרים ושירותים לאורך מחזור החיים שלהם. המסמך מדגיש שהסיכון צריך להיות משולב בניהול הסיכונים הארגוני ולא להישאר רק בתחום הרכש או אבטחת המידע.
עבור ארגונים, המשמעות היא לחבר בין Due Diligence, TPRM, חוזים, Monitoring, Incident Response ו־BCP.
היעד אינו לבדוק כל ספק באותה צורה, אלא לדעת אילו ספקים קריטיים, איזה סיכון הם יוצרים ואיך מנהלים אותו לאורך זמן.

מקורות מרכזיים

• NIST, SP 800-161 Rev. 1 – Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, מאי 2022, כולל עדכונים עד 1.11.2024.
• NIST, Cybersecurity Supply Chain Risk Management for Systems and Organizations.
• NIST, NIST Updates Cybersecurity Guidance for Supply Chain Risk Management, מאי 2022.
• NIST CSRC, Cybersecurity Supply Chain Risk Management – Publications, הכולל גם SP 1326 ומסמכי C-SCRM נוספים.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי.

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך בעזרת בינה מלאכותית ואנושית על ידי רועי קיש, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).