CMMC: רגולציית הסייבר שמשנה את כללי המשחק בתעשייה הביטחונית וספקי DoD

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

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

על רקע זה פותחה CMMC – Cybersecurity Maturity Model Certification: מסגרת להערכת אמצעי ההגנה שמיישמים ספקים וקבלני משנה המשתייכים ל-Defense Industrial Base.

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

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

מהי CMMC?

CMMC היא מסגרת לבחינת אמצעי ההגנה על מידע ממשלתי שנמצא במערכות של ספקים וארגונים שאינם גופים ממשלתיים אמריקאיים. הסמכה ל-Cybersecurity Maturity Model Certification

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

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

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

שני סוגי המידע שנמצאים בלב CMMC

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

1. FCI – Federal Contract Information

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

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

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

2. CUI – Controlled Unclassified Information

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

הוא עשוי לכלול, בהתאם לחוזה ולתחום הפעילות:

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

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

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

סיווג נתונים: נקודת הפתיחה של CMMC

אי אפשר להגדיר את תחולת CMMC בלי לדעת היכן נמצאים FCI ו-CUI.

אם הארגון אינו יודע לזהות ולסווג את המידע, הוא אינו יכול לקבוע:

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

לכן CMMC אינה מתחילה ב-Firewall, במערכת SIEM או ביישום MFA. היא מתחילה ב-Data Discovery, מיפוי זרימות מידע וסיווג נתונים.

תהליך סיווג אפקטיבי צריך להגדיר בצורה ברורה:

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

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

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

Fortra DCS: תמיכה טכנולוגית בסיווג נתונים

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

Fortra Data Classification Suite – DCS, המיושמת בישראל באמצעות מסג׳נט, מאפשרת לארגונים לזהות, לסווג ולתייג מידע בהתאם לרמת הרגישות שלו ולכללי המדיניות הארגונית.

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

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

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

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

שלוש הרמות של CMMC

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

CMMC Level 1

Level 1 מיועדת בעיקר לארגונים המטפלים ב-FCI.

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

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

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

CMMC Level 2

Level 2 היא הרמה המרכזית עבור ארגונים המעבדים, מאחסנים או מעבירים CUI.

היא מבוססת על דרישות NIST SP 800-171 וכוללת נושאים כגון:

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

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

NIST SP 800-171 נועד להגן על סודיות CUI כאשר המידע נשמר במערכות של ארגונים שאינם ממשלתיים. NIST SP 800-171A משלים אותו באמצעות מתודולוגיה לבחינת יישום הדרישות.

CMMC Level 3

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

היא מתבססת על דרישות Level 2 ומוסיפה דרישות הגנה מוגברות, הנבחנות במסגרת הערכה ממשלתית מתאימה.

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

CMMC כחלק מסטנדרט גלובלי

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

חברה אינה חייבת להיות אמריקאית כדי לפגוש דרישות CMMC. כאשר היא מעבדת, מאחסנת או מעבירה FCI או CUI במסגרת התקשרות רלוונטית, הדרישה עשויה להגיע אליה ישירות או באמצעות Flow-Down מקבלן ראשי.

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

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

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

עם זאת, ISO 27001 אינו מחליף CMMC.

ה-Scope של הסמכת ISO עשוי להיות שונה מסביבת ה-CUI, חלק מהבקרות נבחרות בהתאם לסיכון, וב-CMMC נדרשת התאמה ישירה יותר לדרישות NIST ולשיטת ההערכה החוזית.

לכן ארגון מוסמך ISO 27001 עדיין נדרש לבצע Mapping ו-Gap Assessment ייעודיים. ניתן להיעזר גם בהנחיות ISO 27002 ליישום בקרות אבטחת מידע כדי לתרגם את מערך ניהול הסיכונים לבקרות ולראיות תפעוליות.

ההשפעה על התעשייה הביטחונית בישראל

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

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

תנאי סף במכרזים ובהתקשרויות

מוכנות CMMC עשויה להשפיע על היכולת להשתתף במכרז, לקבל הזמנה מקבלן ראשי או להמשיך התקשרות קיימת.

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

הקשחת בדיקות הספקים

חברות ישראליות צפויות לקבל יותר:

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

הפרדת סביבות מידע

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

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

שינוי בניהול ספקים

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

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

אחריות של ההנהלה

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

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

יתרון תחרותי לספקים מוכנים

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

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

הגדרת Scope: ההחלטה שמשפיעה על כל תהליך ההיערכות

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

בפועל, ה-Scope עשוי לכלול:

• שרתים ותחנות קצה
• סביבות ענן
• דואר אלקטרוני
• מערכות שיתוף קבצים
• מערכות ERP ו-CRM
• סביבות פיתוח
• מערכות ניהול פרויקטים
• מערכות גיבוי
• ציוד תקשורת
• גישה מרחוק
• שירותי MSP ו-IT
• ספקי ענן
• קבלני משנה

ככל שהמידע מפוזר ביותר מערכות, כך ה-Scope רחב ומורכב יותר.

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

CMMC אינה פרויקט טכנולוגי בלבד

אחת הטעויות הנפוצות היא להניח שניתן לעמוד ב-CMMC באמצעות רכישת כלי אבטחה.

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

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

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

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

לכן היערכות אפקטיבית צריכה לחבר בין:

מדיניות → תהליכים → תצורה טכנולוגית → פעילות שוטפת → Evidence.

תחומי הבקרה המרכזיים שארגון צריך לבחון

ניהול זהויות והרשאות

הארגון צריך לדעת מי ניגש ל-FCI ול-CUI, באיזו הרשאה, מאיזו מערכת ולשם איזו מטרה.

נדרשים בדרך כלל:

• זיהוי משתמשים ייחודי
• הרשאות לפי תפקיד
• Least Privilege
• הפרדת סמכויות
• MFA במקומות הרלוונטיים
• סקירות הרשאה תקופתיות
• תהליך Joiner-Mover-Leaver
• בקרה על חשבונות שירות
• תיעוד אישורים וחריגים

ניהול נכסים ותצורה

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

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

לוגים וניטור

לא מספיק להפעיל לוגים. צריך להגדיר:

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

תגובה לאירועי סייבר

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

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

ניהול ספקים וקבלני משנה

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

לפני העברת מידע לספק משנה יש לבדוק:

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

הדרכות עובדים

עובדים שנחשפים ל-CUI צריכים לדעת לזהות אותו ולהבין כיצד מותר לטפל בו.

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

SSP: המסמך שמחבר בין הדרישה למציאות

System Security Plan, או SSP, הוא אחד ממסמכי הליבה בהיערכות להגנת CUI.

המסמך מתאר:

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

SSP איכותי אינו אוסף של הצהרות כלליות. הוא צריך לשקף את המערכות והתהליכים כפי שהם פועלים בפועל.

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

POA&M: תוכנית לניהול פערים

Plan of Action and Milestones הוא כלי לניהול פערים שטרם נסגרו.

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

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

עם זאת, POA&M אינו מאפשר לדחות כל דרישה ואינו מהווה תחליף ליישום הבקרות. קיימות מגבלות על סוג הפערים שניתן להשאיר פתוחים ועל פרק הזמן שניתן לסגירתם.

Evidence: לא מספיק לבצע – צריך להוכיח

CMMC דורשת ראיות אובייקטיביות לכך שהבקרות מיושמות.

Evidence עשוי לכלול:

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

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

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

מה מצב CMMC נכון לאוגוסט 2026?

היישום החוזי של CMMC החל בנובמבר 2025 במסגרת Phase I.

ב-13 ביולי 2026 הודיע הממשל האמריקאי על השעיית דרישות Phase II, שתוכננו להיכנס לתוקף בנובמבר 2026, כחלק מתהליך לבחינת המסגרת ולהפחתת נטל הציות.

עם זאת, דרישות Phase I המבוססות על Self-Assessments נותרו בתוקף.
בתקופת הבחינה ממשיכות גם דרישות ההגנה הקיימות על CUI והערכות רלוונטיות לפי NIST SP 800-171.

מבחינת ארגונים, השעיית Phase II אינה סיבה לעצור את ההיערכות.

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

כיצד נכון להתחיל להיערך?

1. בדיקת תחולה

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

צריך להבין:

• האם הארגון מחזיק FCI או CUI
• מהי רמת CMMC הנדרשת
• אילו מערכות משתתפות בביצוע החוזה
• האם הדרישות מועברות לספקים נוספים

2. מיפוי וסיווג מידע

יש לזהות את סוגי המידע, מקורותיהם, מיקומם ונתיבי ההעברה שלהם.

3. הגדרת Scope

יש לקבוע אילו מערכות, משתמשים, מתקנים וספקים נכללים בסביבת CMMC.

4. ביצוע סקר פערים

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

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

5. ביצוע סקר סיכונים

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

6. כתיבת SSP ותוכנית תיקון

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

7. יישום בקרות ואיסוף Evidence

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

8. בדיקת מוכנות

לפני הערכה רשמית, מומלץ לבצע Readiness Assessment כדי לזהות פערים בין הדרישות, היישום והראיות.

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

9. הכנות להסמכה ותקינה NIST SP 800-171

10. בחינת סיווג הנתונים בארגון ו-DATA Classification

11. תקן ISO 27001 מקדם את תוכניות ההסמכה ויכול לספק את הבסיס ל-SSP שהוא תנאי לתקינה

כיצד אינפוגארד יכולה לסייע בהיערכות ל-CMMC?

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

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

תהליך הליווי עשוי לכלול:

• בדיקת Applicability
• ניתוח חוזים ודרישות לקוח
• זיהוי FCI ו-CUI
• מיפוי מידע ו-Data Flow
• הגדרת Scope
• Gap Assessment מול דרישות CMMC ו-NIST
• סקר סיכוני אבטחת מידע
• כתיבה ועדכון של SSP
• בניית POA&M
• סקירת מדיניות ונהלים
• בחינת הרשאות וזהויות
• מיפוי ספקים וקבלני משנה
• בניית מנגנון Evidence
• הכנה להערכה עצמית או חיצונית
• ליווי הנהלה ומעקב אחר תוכנית העבודה

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

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

CMMC אינה עוד תקן שאפשר לסמן עליו וי.

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

עבור התעשייה הביטחונית בישראל, המשמעות המרכזית היא הצורך לבנות יכולת מוכחת בתחומים הבאים:

• זיהוי וסיווג FCI ו-CUI
• מיפוי זרימות מידע
• הגדרת Scope
• הפרדת סביבות
• ניהול הרשאות
• ניהול ספקים וקבלני משנה
• תיעוד ואיסוף Evidence
• אחריות הנהלה
• שמירה על עמידה לאורך זמן

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

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

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

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

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

שאלות נפוצות על CMMC

האם CMMC היא תקן בינלאומי?

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

האם חברה ישראלית יכולה להידרש ל-CMMC?

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

מה ההבדל בין FCI ל-CUI?

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

האם ISO 27001 מחליף CMMC?

לא. ISO 27001 מספק בסיס ניהולי טוב, אך יש לבצע מיפוי וסקר פערים ייעודיים מול דרישות CMMC, ‏NIST והחוזה הרלוונטי.

האם כל מערכות הארגון צריכות להיכלל ב-Scope?

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

האם כלי לסיווג נתונים מספיק לצורך עמידה ב-CMMC?

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

מהו הצעד הראשון בהיערכות?

הצעד הראשון הוא לבדוק את החוזים ולזהות האם הארגון מקבל, יוצר, מעבד, מאחסן או מעביר FCI או CUI.

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