NIST מפרסם Revision 2 לתרן NIST SP 800-18 אחרי כמעט 20 שנה

ב-30 ביוני 2026 פרסם NIST את SP 800-18 Revision 2 – Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems. הגרסה החדשה מחליפה את Revision 1, שפורסמה בפברואר 2006.

זהו שינוי משמעותי לא רק בגלל הזמן שחלף.

המסמך כבר אינו עוסק רק ב-"Guide for Developing Security Plans", אלא בתכנון משולב של:

• Security
• Privacy
• Cybersecurity Supply Chain Risk Management – C-SCRM

NIST מכנה את שלושת המסמכים יחד System Plans.

מ-SSP אחד לשלוש תוכניות מערכת מחוברות

בגרסה החדשה NIST מתייחס לשלושה סוגים מרכזיים של System Plans:

System Security Plan

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

System Privacy Plan

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

C-SCRM Plan

Cybersecurity Supply Chain Risk Management Plan מתמקד בסיכונים הנוצרים כתוצאה מספקים, רכיבים, שירותים, שרשרת פיתוח ותלויות חיצוניות. גם הוא נכנס כעת לתמונה המערכתית שמציג SP 800-18 Rev. 2.

המשמעות היא שהסתכלות על מערכת כעל "שרתים + Firewall + הרשאות" כבר אינה מספיקה.

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

למה השינוי הזה חשוב?

מערכות מודרניות כמעט אף פעם אינן עומדות לבדן.

יישום ארגוני טיפוסי יכול להסתמך על:

• ספק Cloud
• SaaS
• API חיצוני
• ספריות תוכנה
• Managed Service Provider
• ספק Identity
• שירותי Monitoring
• מערכות Backup
• קבלני פיתוח
• ספקי תמיכה

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

ב-SP 800-18 Rev. 2, NIST מרכז במסגרת ה-System Plans מידע על המערכות והאנשים שמוגנים בתוך Authorization Boundary ועל מערכות מחוברות, לצד מידע על Data Flows, רכיבים, סביבת הפעילות ובקרות קיימות או מתוכננות.

החיבור ל-Risk Management Framework מתחזק

אחד השינויים החשובים ב-Revision 2 הוא החיבור הישיר יותר ל-NIST Risk Management Framework – RMF.

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

המשמעות היא שה-SSP אינו אמור לחיות במקביל לתהליך ניהול הסיכונים.

הוא צריך להיות חלק ממנו.

כאשר הארגון:

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

ה-System Plans צריכים לשקף את ההחלטות האלה.

למי שרוצה להעמיק בתפיסה הרחבה יותר של NIST, ניתן לקרוא גם את המאמר בנושא -NIST Cybersecurity Framework 2.0.

לא רק אבטחה: Privacy נכנסת לאותה תמונת מערכת

שינוי נוסף הוא המקום שמקבלת פרטיות.

NIST אינו מציג Privacy כתוספת בסוף פרויקט האבטחה, אלא כחלק ממערך תכנון הסיכונים של המערכת. שלושת סוגי התוכניות — Security, Privacy ו-C-SCRM — מוצגים כמסמכים מחוברים המתארים את המערכת ואת החלטות ניהול הסיכון סביבה.

עבור ארגון, המשמעות היא שכדאי לחבר בין שאלות כמו:

• איזה מידע אישי המערכת אוספת?
• מדוע הוא נדרש?
• מי יכול לגשת אליו?
• לאן הוא מועבר?
• כמה זמן הוא נשמר?
• אילו צדדים שלישיים מעבדים אותו?
• אילו סיכוני פרטיות נוצרים מהשימוש במערכת?

לבין עבודת ה-System Planning הרגילה.

הגישה הזו מתחברת גם למסגרות ניהול פרטיות כגון ISO 27701 או תיקון 13 לחוק הגנת הפרטיות, שבהן פרטיות מנוהלת כחלק ממערכת Governance מתועדת הכוללת Scope, אחריות, הערכת פערים, תהליכים ו-Evidence.

שרשרת האספקה הופכת לחלק מה-System Plan

אחד הביטויים הבולטים ביותר להתפתחות עולם הסייבר הוא הכנסת Cybersecurity Supply Chain Risk Management לתוך SP 800-18.

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

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

הוא נמצא גם ב:

• רכיבי תוכנה
• ספקי Cloud
• ספקי SaaS
• עדכוני תוכנה
• ספקי פיתוח
• Managed Services
• רכיבי חומרה
• גורמי תמיכה בעלי גישה

ה-C-SCRM Plan נועד לאפשר לארגון לתעד כיצד סיכוני שרשרת האספקה משתלבים בהחלטות ניהול הסיכון של המערכת. NIST גם פרסם לצד Revision 2 דוגמה נפרדת ל-C-SCRM Plan המבוססת על התפיסה של SP 800-161 Rev. 1.

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

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

NIST מדגיש ב-Revision 2 שימוש ב-Machine-Readable Data Formats לצורך איסוף מידע אוטומטי ושילוב עם פלטפורמות נפוצות, ובהן:

• GRC
• SOAR
• SIEM

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

זה שינוי תפיסתי חשוב.

במקום:

SSP.docx → נכתב → נשמר → נפתח שוב לפני ביקורת

הכיוון הוא:

System Data → Controls → Evidence → Monitoring → Risk Decisions

כאשר חלק מהמידע יכול להתעדכן באופן מתמשך.

האם זה אומר שמסמכי Word נעלמים?

לא.

NIST מדגיש שארגונים שעדיין עובדים עם System Plans מבוססי מסמכים יכולים להמשיך לעשות זאת, ואף פרסם לצד Revision 2 תבניות לדוגמה עבור:

• System Security Plan
• System Privacy Plan
• C-SCRM Plan
• Roles & Responsibilities

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

כלומר, NIST אינו מבטל את המסמך.

הוא משנה את החשיבה עליו.

ה-SSP הופך מ-"מסמך אבטחה" למרכז מידע

אחד הרעיונות החזקים בעדכון הוא הפיכת ה-System Plans לנקודת Reference מרכזית להחלטות ניהול סיכון.

לפי NIST, התוכניות מרכזות מידע בין היתר על:

• מידע שנוצר
• מידע שנאסף
• מידע שמופץ
• שימוש במידע
• אחסון
• Disposal
• גורמי אחריות
• סביבת הפעלה פנימית וחיצונית
• רכיבי מערכת
• Data Flows
• בקרות קיימות ומתוכננות

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

שינוי גם בטרמינולוגיה

Revision 2 פורש חלק מהמונחים הוותיקים ששימשו לסיווג מערכות, בהם General Support System ו-Major Application, ועובר לטרמינולוגיה שמתאימה יותר לדרישות ולטכנולוגיות מודרניות.

גם זה אינו שינוי קוסמטי בלבד.

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

מה זה אומר לארגון שכבר מחזיק SSP?

אין צורך למחוק את ה-SSP הקיים ולהתחיל מאפס.

אבל כן כדאי לבצע Review.

כדאי לבדוק האם המסמך מתאר:

• System Boundary עדכני
• רכיבי מערכת
• Internal ו-External Environment
• Data Flows
• סוגי מידע
• מערכות מחוברות
• בקרות קיימות
• בקרות מתוכננות
• בעלי תפקידים
• אחריות לתחזוקה
• שירותים וספקים חיצוניים

ובנוסף לשאול:

• האם Privacy מקבלת התייחסות מספקת?
• האם סיכוני Supply Chain מתועדים?
• האם הספקים המשמעותיים ממופים?
• האם החלטות Risk Management מקושרות ל-SSP?
• האם המידע במסמך מתעדכן כאשר המערכת משתנה?
• האם ניתן לחבר חלק מה-Evidence למערכות GRC, SIEM או מערכות תפעול אחרות?

להרחבה על מבנה SSP ניתן לקרוא את המדריך ל-System Security Plan של אינפוגארד.

ומה הקשר ל-ISO 27001?

ISO 27001 אינו דורש SSP באותו מבנה שבו NIST משתמש במונח.

עם זאת, יש חפיפה רבה בחומרי הגלם.

ארגון שמפעיל ISO 27001 מחזיק בדרך כלל מערכת ניהול שעוסקת ב-Scope, סיכונים, אחריות, בקרות, ביקורת ושיפור מתמשך. ISO מגדיר את התקן כמסגרת להקמה, יישום, תחזוקה ושיפור מתמשך של ISMS.

ההבדל הוא ש-SP 800-18 מתמקד באופן מפורש יותר בתכנון ברמת המערכת.

לכן ארגון שפועל לפי ISO יכול להשתמש בחלק מהתהליכים, המסמכים וה-Evidence שכבר קיימים, ולהרחיב אותם לתמונה מערכתית בהתאם ל-NIST.

ומה הקשר ל-CMMC?

SSP מוכר במיוחד גם לארגונים שמתכוננים ל-CMMC ולדרישות להגנת Controlled Unclassified Information.

לכן העדכון של SP 800-18 חשוב להבנת הכיוון שבו NIST רואה את תחום System Planning, גם אם דרישות CMMC והמסמכים המחייבים במסגרתו צריכים להיבחן לפי הפרסומים והגרסאות הספציפיים שחלים על החוזה.

המסר הרחב נשאר זהה:

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

ומה ארגונים צריכים לעשות עכשיו?

עבור ארגון שכבר מנהל SSP או פועל לפי NIST, כדאי לבצע ארבע פעולות:

1. Review ל-SSP הקיים

בדיקה האם הוא עדיין משקף את המערכת והארכיטקטורה בפועל.

2. הוספת Privacy לתמונה

לא רק Security Controls אלא גם נתונים אישיים, מטרות שימוש, גישה, שיתוף וספקים.

3. מיפוי Supply Chain

זיהוי ספקים, שירותים ורכיבים שיש להם השפעה על הסיכון המערכתי.

4. חיבור Evidence למידע תפעולי

במקום להסתמך רק על מסמכים סטטיים, לבחון אילו נתונים ניתן לקבל ממערכות IAM, ‏SIEM, Vulnerability Management, Cloud ו-GRC.

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

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

העדכון של NIST ממחיש שוב ש-System Planning אינו פרויקט כתיבה.

הוא דורש שילוב של:

• ארכיטקטורה
• ניהול סיכונים
• פרטיות
• ניהול ספקים
• Governance
• בקרות טכנולוגיות
• Evidence
• תחזוקה מתמשכת

אינפוגארד מסייעת לארגונים לבצע:

• סקירת SSP קיים
• הגדרת Scope ו-System Boundary
• מיפוי Data Flows
• מיפוי בקרות
• GAP Assessment
• סקר סיכונים
• מיפוי צדדים שלישיים
• חיבור דרישות Privacy
• בניית Evidence
• הכנה להערכות וביקורות
• התאמה בין NIST למסגרות ISO ו-Compliance קיימות

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

חשוב להפנים NIST SP 800-18 Rev. 2 הוא הרבה יותר מעדכון טכני למסמך בן עשרים שנה.

הוא משקף שינוי באופן שבו NIST מסתכל על מערכת מודרנית: Security, Privacy ו-Supply Chain Risk כבר אינם עולמות נפרדים.

הם חלק מאותה תמונת סיכון.

ה-System Security Plan נשאר רכיב מרכזי, אבל הוא מצטרף כעת באופן ברור יותר ל-System Privacy Plan ול-C-SCRM Plan. במקביל, NIST מחבר את תוכניות המערכת ל-RMF ומעודד שימוש במידע מובנה ובאוטומציה כדי לצמצם תלות בתיעוד סטטי.

עבור ארגונים, המסר הפרקטי הוא פשוט:

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

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

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

בניית SSP איכותי מחייבת חיבור בין ידע טכנולוגי, ניהול סיכונים, תקינה ו-Governance.

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

הליווי יכול לכלול:

• הגדרת Scope
• מיפוי מערכות ונכסי מידע
• Data Flow Mapping
• סקר סיכוני אבטחת מידע
• Gap Assessment
• מיפוי בקרות
• הגדרת Roles & Responsibilities
• סקירת ספקים ושירותי צד שלישי
• איסוף והגדרת Evidence
• כתיבה וסקירה של נהלים ומסמכי אבטחה
• הכנה לביקורות ו-Assessments
• בניית מנגנון לעדכון מתמשך

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

System Security Plan הוא כלי בסיסי לניהול סיכוני סייבר ואבטחת מידע

זהו כלי מרכזי בתפיסת ניהול הסיכון של NIST, הוא מופיע בדרישות להגנת CUI ומשתלב גם בתהליכי Authorization ובמסגרות פדרליות נוספות.

תקנים כמו ISO 27001 משתמשים בשפה ובמבנה שונים, אך גם בהם העקרונות של Scope, ניהול סיכונים, בקרות, אחריות ותיעוד נמצאים בליבת התהליך.

ככל שהעולם עובר מ-Compliance המבוסס על הצהרות ל-Assurance המבוסס על ראיות, החשיבות של SSP ושל מסמכים דומים רק גדלה.

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

הוא גם מנהל את סיכוני הסייבר שלו טוב יותר.

יצירת קשר עם מומחי SSP של אינפוגארד

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