בלוג

CTEM: למה ניהול פגיעויות וסריקת חולשות כבר לא מספיק ב-2026?

ארגונים רבים מתמודדים עם אלפי ממצאי אבטחה, אך לא כל חולשה מייצגת את אותה רמת סיכון. CTEM – Continuous Threat Exposure Management – נועד לזהות אילו חשיפות באמת יכולות להוביל לפגיעה בנכסים הקריטיים של הארגון. במאמר נבחן את ההבדל בין CTEM לניהול פגיעויות, את היתרונות של כל גישה ואת הדרך לשלב ביניהן.
CTEM Shield Continuous Threat Exposure Management

CTEM מול ניהול פגיעויות: למה רשימת חולשות כבר לא מספיקה?

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

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

כאן נכנסת גישת CTEM Continuous Threat Exposure Management, או בעברית: ניהול רציף של חשיפות לאיומי סייבר.

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

ניהול פגיעויות אומר מה פגיע.

CTEM עוזר להבין מה באמת מסוכן לארגון.
CTEM Shield Continuous Threat Exposure Management

מהו CTEM?

CTEM הוא מודל לניהול רציף של כלל החשיפות שעלולות לאפשר פגיעה בארגון.

הדגש הוא על המילה Exposure – חשיפה. חשיפה אינה חייבת להיות חולשת תוכנה. היא יכולה להיות גם:

  • מערכת ענן שהוגדרה באופן שגוי.
  • נכס אינטרנטי שאינו מוכר לצוות ה־IT.
  • משתמש ללא MFA.
  • חשבון שירות ישן.
  • הרשאה עודפת.
  • תחנת קצה שאינה מנוהלת.
  • API חשוף.
  • תוסף SaaS בעל גישה רחבה.
  • קשר בין כמה מערכות שיוצר נתיב תקיפה.

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

המשמעות היא מעבר משאלה צרה:

“אילו חולשות קיימות?”

לשאלה רחבה יותר:

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

CTEM בוחן נתיבי תקיפה ולא רק ממצאים בודדים

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

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

  1. מערכת חשופה לאינטרנט.
  2. משתמש בעל הרשאות לא מתאימות.
  3. גישה ממשתמש זה למשאב ענן.
  4. חיבור מהמשאב למאגר מידע רגיש.

כל אחד מהפערים עשוי להיראות מוגבל כשהוא נבחן בנפרד. יחד הם יוצרים Attack Path.

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

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

The 5 Stages of CTEM Infographic

חמשת השלבים של CTEM

CTEM מתואר בדרך כלל כתהליך מחזורי הכולל חמישה שלבים מרכזיים:

1. Scoping – הגדרת היקף

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

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

2. Discovery – גילוי חשיפות

בשלב זה אוספים מידע על חולשות, נכסים, תצורות, זהויות, הרשאות, מערכות ענן, שירותים חיצוניים ו־Shadow IT.

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

3. Prioritization – תעדוף

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

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

כך נמנעת הסתמכות בלעדית על חומרה טכנית.

4. Validation – אימות

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

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

5. Mobilization – הנעת הטיפול

זהו השלב שבו הממצאים הופכים לתוכנית עבודה:

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

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

מהו ניהול פגיעויות?

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

התהליך כולל בדרך כלל:

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

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

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

גם CISA ממליצה להשתמש ב-Known Exploited Vulnerabilities Catalog כאחד הקלטים לתעדוף, משום שהוא מצביע על חולשות שקיימות לגביהן ראיות לניצול בפועל. כלומר, אפילו בתוך עולם ניהול הפגיעויות, דירוג טכני לבדו אינו מספיק.

למה דירוג CVSS אינו מספר את כל הסיפור?

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

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

כדי לתעדף נכון צריך לשאול:

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

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

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

Vulnerability לעומת Exposure

ההבדל בין שני המונחים חשוב.

Vulnerability היא חולשה ברכיב, תוכנה או מערכת.

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

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

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

CTEM לא מתעלם מהחולשות. הוא מציב אותן בתוך הקשר רחב יותר.

CTEM מול ניהול פגיעויות

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

אפשר לסכם זאת כך:

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

מדוע CTEM אינו מחליף ניהול פגיעויות סייבר ואבטחת מידע?

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

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

ההבדל הוא ש-CTEM מוסיף לנתונים האלה הקשר:

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

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

הקשר בין CTEM, סקרי סיכונים ו-GRC

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

לדוגמה:

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

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

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

Data privacy Officer as a service outsource privacy management

ומה הקשר בין CTEM לפרטיות?

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

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

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

CISO cyber-security SHIELD

מה המשמעות עבור ה-CISO והנהלת הארגון?

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

במקום להגיע להנהלה עם אמירה כמו:

“יש בארגון 7,000 חולשות, מהן 500 קריטיות”,

ניתן להגיע עם מסר ברור יותר:

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

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

היא מאפשרת להנהלה להבין:

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

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

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

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

אפשר להתקדם באופן מדורג:

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

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

Infoguard Cybersecurity  protection in a digital world

איך אינפוגארד מסייעת?

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

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

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

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

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

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

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

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

/ 5.

בלוג

הישארו תמיד צעד קדימה

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

KNon-Human Identity Shield Network

5 דק׳ קריאה

Non-Human Identities: הזהויות החדשות שארגונים חייבים להתחיל לנהל

מהן Non-Human Identities, מדוע Service Accounts ו-AI Agents הופכים לאתגר אבטחה משמעותי, ואיך מנהלים הרשאות, Secrets, Zero Trust ו-Governance?
NIST AI RMF Framework

5 דק׳ קריאה

NIST AI Risk Management Framework: כך מנהלים סיכוני AI בארגון

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

5 דק׳ קריאה

בלוג אורח – הטמעת AI בארגון ולצמצם את סיכון המידע: מדריך אבטחה ל-2026 – אדיר נוריאל

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

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

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

אנו זמינים עבורכם לייעוץ מקצועי

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

דברו איתנו

077-9011117

בקרו אותנו

השחם 1 פתח תקווה, 4951701 ת.ד 11058 בסר סיטי בניין C קומה 11

תכתבו לנו

sales@infoguard.co.il