מהו SSP ולמה הוא הופך למסמך מפתח בעמידה בדרישות סייבר?

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

איפה נמצאת התמונה המלאה?

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

בדיוק בנקודה הזו נכנס לתמונה SSP – System Security Plan.

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

מהו System Security Plan?

System Security Plan הוא מסמך המתאר את סביבת המערכת ואת הדרך שבה הארגון מגן עליה.

בגרסה העדכנית של NIST SP 800-18 Revision 2, שפורסמה ביוני 2026, NIST מגדיר System Plans כמסמכים המתארים בין היתר את מטרת המערכת, מצב הבקרות שנבחרו לצורך ניהול הסיכון ואת תחומי האחריות של האנשים שמנהלים, תומכים וניגשים למערכת. העדכון החדש מרחיב את תפיסת התכנון גם לתחומי פרטיות וניהול סיכוני שרשרת אספקת סייבר.

במילים פשוטות, SSP אמור לענות על השאלה:

"איך המערכת הזו מוגנת בפועל, ועל סמך מה אנחנו יודעים שההגנה הזו קיימת?"

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

• מטרת המערכת
• גבולות המערכת – System Boundary
• נכסים ורכיבים
• סוגי המידע
• משתמשים והרשאות
• מערכות מחוברות ותלויות
• ספקים ושירותי צד שלישי
• איומים וסיכונים
• דרישות אבטחה
• בקרות קיימות ומתוכננות
• בעלי תפקידים ואחריות
• Evidence המוכיח שהבקרות פועלות

למה SSP הופך להיות משמעותי יותר?

עולם ה-Compliance משתנה.

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

היום הדרישה הולכת ומתקרבת ל-Evidence-Based Assurance: לא רק מה הארגון התחייב לעשות, אלא מה באמת קורה בתוך המערכת.

לכן שאלות כמו אלה הופכות לקריטיות:

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

SSP מרכז את התשובות במקום אחד.

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

מה צריך לכלול SSP טוב?

אין תבנית אוניברסלית אחת שמתאימה לכל ארגון ולכל רגולציה.

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

1. תיאור המערכת

צריך להתחיל בהסבר ברור:

• מה המערכת עושה?
• מה התפקיד העסקי שלה?
• מי המשתמשים?
• מי הבעלים?
• באילו אתרים או סביבות היא מופעלת?

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

2. System Boundary

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

ה-SSP צריך להבהיר מה נמצא בתוך ה-Scope ומה נמצא מחוצה לו.

לדוגמה:

• שרתים
• תחנות קצה
• רכיבי תקשורת
• Cloud Services
• אפליקציות SaaS
• בסיסי נתונים
• כלי ניטור
• מערכות גיבוי
• רכיבי IAM
• מערכות אבטחה
• שירותי MSP

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

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

3. סוגי המידע וזרימות המידע

SSP מודרני אינו יכול להתייחס רק לשרתים.

צריך להבין גם את המידע.

איזה מידע המערכת:

• יוצרת
• מקבלת
• מעבדת
• שומרת
• מעבירה
• משתפת
• מגבה
• מוחקת

NIST SP 800-171 Rev. 3, לדוגמה, דורש במסגרת ה-System Security Plan לזהות את סוגי המידע שהמערכת מעבדת, מאחסנת ומעבירה.

זה הופך את ה-Data Flow לאחד המרכיבים החשובים במסמך.

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

4. רכיבים וארכיטקטורה

ה-SSP צריך להציג תמונה שמאפשרת להבין איך המערכת בנויה.

בדרך כלל רצוי לשלב:

• Network Diagram
• Data Flow Diagram
• רכיבים מרכזיים
• חיבורים בין מערכות
• Trust Boundaries
• ממשקים חיצוניים
• גישה מרחוק
• שירותי Cloud
• תלות בספקים חיצוניים

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

5. דרישות ובקרות אבטחה

זהו לב המסמך.

עבור כל דרישה משמעותית צריך להבין:

מה הדרישה? → איך היא מיושמת? → איפה? → מי אחראי? → איך מוכיחים?

לדוגמה, אם קיימת דרישה לנהל הרשאות, לא מספיק לכתוב:

"Access is restricted to authorized users."

צריך להבין כיצד:

• משתמש נפתח
• הרשאה מאושרת
• MFA מיושם
• הרשאות Privileged מנוהלות
• הרשאות נבדקות
• עובד שעזב מוסר
• פעילות נשמרת בלוגים

ככל שהתיאור קרוב יותר לפעילות האמיתית של הארגון, כך ה-SSP שימושי יותר.

6. Roles & Responsibilities

SSP שלא מגדיר אחריות הופך מהר מאוד למסמך תאורטי.

צריך לדעת מי אחראי על:

• המערכת
• אבטחת המידע
• IAM
• Patch Management
• Incident Response
• Backup
• Monitoring
• שינויי תצורה
• ספקי צד שלישי
• עדכון ה-SSP עצמו

כאן מתחבר ה-SSP ישירות ל-Governance.

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

SSP ו-CMMC: למה שומעים את שני המונחים יחד?

אחת הסיבות לכך שהמונח SSP הופך מוכר יותר היא CMMC.

הדרישות להגנת Controlled Unclassified Information במערכות של קבלנים וספקים אמריקאיים נשענות על NIST SP 800-171.

ב-NIST 800-171 Rev. 3 קיימת דרישה מפורשת לפתח System Security Plan הכולל בין היתר:

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

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

מכאן מגיע החיבור החזק ל-CMMC.

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

אבל חשוב להדגיש:

SSP אינו "מסמך של CMMC".

CMMC הוא רק אחד המקרים שבהם חשיבותו הופכת מאוד ברורה.

SSP ו-NIST Risk Management Framework

השורשים של SSP רחבים יותר מעולם CMMC.

בתפיסת ה-NIST Risk Management Framework – RMF, ניהול אבטחה מבוסס על מחזור חיים: להבין את המערכת, לסווג אותה, לבחור בקרות, ליישם אותן, להעריך את האפקטיביות שלהן, לאשר את הסיכון ולנטר לאורך זמן.

System Security Plan משמש כנקודת חיבור בין השלבים האלה.

הוא מאפשר לתעד:

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

העדכון החדש של NIST 800-171 מחזק בדיוק את התפיסה הזאת ומחבר את תוכניות המערכת באופן ישיר יותר למשימות ולשלבים של RMF.

SSP ו-NIST SP 800-53

גם קטלוג הבקרות המרכזי של NIST, ‏SP 800-53, כולל את תפיסת ה-System Security and Privacy Plan.

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

העיקרון החשוב כאן הוא שה-SSP אינו "נספח טכני".

הוא חלק מתהליך Planning של אבטחת המידע.

ומה הקשר ל-FedRAMP?

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

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

עם זאת, יש כאן התפתחות חשובה ועדכנית.

ב-2026 FedRAMP החל לעבור למודל חדש שבו, עבור Cloud Service Providers, ‏Security Decision Record מחליף בהדרגה את ה-System Security Plan המסורתי כרשומה מתמשכת של החלטות האבטחה לאורך חיי השירות. במקביל, Agency System Security Plan ממשיך לשמש סוכנויות בתיעוד הדרך שבה שירות הענן משולב בתוך המערכת שלהן.

זו דוגמה טובה לכך שהשם והפורמט יכולים להשתנות — אבל הצורך נשאר:

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

SSP ו-ISO 27001: דומה, אבל לא אותו דבר

חשוב לעשות כאן הבחנה.

הסמכה לתקן ISO/IEC 27001 אינה דורשת מסמך בשם System Security Plan אך תקן ISO 27001 מקדם ומקל על בניית SSP.

ISO 27001 עוסק בהקמה ובתחזוקה של Information Security Management System – ISMS, מערכת ניהול אבטחת מידע המבוססת על ניהול סיכונים ושיפור מתמשך.

ארגון שעובד בצורה מסודרת לפי ISO 27001 כבר מחזיק חלק משמעותי מחומרי הגלם הדרושים ל-SSP:

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

אבל יש הבדל בגישה.

ISO 27001 מסתכל על מערכת ניהול אבטחת המידע של הארגון. SSP יורד לרמת המערכת ומסביר כיצד הדרישות והבקרות מיושמות בסביבה מוגדרת.

לכן הם משלימים זה את זה.

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

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

SSP וסקר סיכונים: שני מסמכים שונים שמשלימים זה את זה

גם SSP אינו תחליף לסקר סיכונים.

סקר סיכונים שואל:

"מה יכול להשתבש, מה ההשפעה ומה סדר העדיפויות לטיפול?"

SSP שואל:

"איך המערכת בנויה ואיך אנחנו מגינים עליה?"

הראשון עוזר לקבל החלטות.

השני מתעד את המימוש של חלק גדול מאותן החלטות.

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

תוכנית הטיפול עשויה לקבוע MFA, ‏Role-Based Access, סקירת הרשאות ותהליך Offboarding.

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

הקשר בין SSP ל-Evidence

אחד ההבדלים בין SSP שימושי לבין "עוד מסמך למגירה" הוא ה-Evidence.

לכל בקרה משמעותית רצוי שניתן יהיה לחבר ראיה.

לדוגמה:

בקרה	יישום	Evidence אפשרי
MFA	מופעל למשתמשים מורשים	הגדרות IAM
סקירת הרשאות	סקירה רבעונית	דוח Review חתום
Patch Management	תהליך חודשי	דוחות Patch
גיבויים	גיבוי יומי	Logs + בדיקת Restore
הדרכת עובדים	הדרכה שנתית	רישומי השתתפות
Incident Response	נוהל ותרגול	דוח תרגיל
ניהול ספקים	Assessment לפני התקשרות	שאלון וסיווג ספק

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

בדיוק בנקודה הזו GAP Assessment הופך משמעותי: הבדיקה אינה מסתפקת בקיום מסמכים, אלא בוחנת יישום בפועל ואוספת Evidence כאשר הדבר נדרש.

אחת הטעויות הגדולות: SSP שנכתב רק פעם אחת

מערכות משתנות כל הזמן.

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

אם ה-SSP נשאר כפי שנכתב לפני שנתיים, הוא כבר אינו מתאר את המערכת.

לכן יש להתייחס אליו כאל Living Document.

NIST SP 800-171 Rev. 3 אף כולל דרישה מפורשת לבחון ולעדכן את ה-System Security Plan בתדירות שהארגון מגדיר.

מומלץ לקבוע טריגרים לעדכון גם מעבר לבדיקה התקופתית:

• שינוי משמעותי בארכיטקטורה
• מעבר לענן
• הוספת ספק משמעותי
• מערכת חדשה
• שינוי Data Flow
• שינוי בסוג המידע
• Incident משמעותי
• שינוי בדרישות רגולציה
• ממצא Audit משמעותי

מי צריך להיות מעורב בכתיבת SSP?

SSP אינו אמור להיכתב רק על ידי איש Compliance.

כתיבה איכותית מחייבת בדרך כלל מעורבות של:

• CISO
• מנהל IT
• System Owner
• מנהלי תשתיות
• Cloud / DevOps
• בעלי אפליקציות
• אנשי GRC
• מנהל פרטיות לפי הצורך
• רכש וניהול ספקים
• בעלי תהליכים עסקיים

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

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

איך מתחילים לבנות SSP?

תהליך נכון יכול להתחלק למספר שלבים:

שלב 1 – מגדירים את המטרה

האם המסמך נדרש בגלל:

• CMMC?
• דרישת לקוח?
• NIST?
• פרויקט ממשלתי?
• Cloud Authorization?
• צורך פנימי של הארגון?

המטרה תקבע את עומק התיעוד ואת דרישות ה-Evidence.

שלב 2 – מגדירים Scope

ממפים מערכות, נכסים, משתמשים, ממשקים, ספקים ומיקומים.

שלב 3 – ממפים מידע ו-Data Flow

מבינים איזה מידע נכנס, יוצא, נשמר ומעובד.

שלב 4 – ממפים דרישות לבקרות

לכל דרישה מגדירים:

• בקרה קיימת
• מערכת אחראית
• בעל תפקיד
• תדירות
• Evidence
• פערים

שלב 5 – מזהים פערים

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

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

שלב 6 – מגדירים תהליך תחזוקה

SSP טוב צריך Owner ותאריך עדכון.

אחרת הוא יהפוך במהירות למסמך היסטורי.

SSP הוא לא המטרה – הוא תמונת המצב

קל להפוך SSP לפרויקט Documentation.

זו טעות.

המטרה אינה להגיע למסמך של מאה עמודים.

המטרה היא להגיע למצב שבו הארגון מסוגל לענות בצורה ברורה על ארבע שאלות:

1. מה אנחנו מגינים עליו?
2. מפני מה אנחנו מגינים עליו?
3. איך אנחנו מגינים עליו?
4. איך אנחנו מוכיחים שזה באמת קורה?

אם ה-SSP מצליח לענות עליהן, הוא הופך לכלי ניהול.

אם הוא רק משכפל טקסטים מתוך תקן, הוא הופך לעוד מסמך 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).