מבדקי חדירה למערכות תמיכה בעקבות הפריצה ל-DIVD
בהזמנת בדיקת אבטחה, קל להתמקד באתר ובמוצר שהלקוחות משתמשים בו. במסגרת מבדקי חדירה כדאי לבחון גם את מערכת התמיכה: אילו פניות ומסמכים היא מחזיקה, מי יכול לגשת אליהם ולאילו מערכות היא מחוברת. הפריצה ל-DIVD, שעליה פורסמו פרטים נוספים בתחילת אוקטובר 2026, נותנת סיבה טובה לבדוק אם המערכת הזאת נכללת בתוכנית הבדיקות שלכם.
מה פורסם על הפריצה ל-DIVD
המכון ההולנדי לחשיפת חולשות, Dutch Institute for Vulnerability Disclosure או DIVD, פרסם ב-24 בספטמבר 2026 הודעה על פריצה לתשתיותיו. לפי תיק האירוע הרשמי, שעודכן ב-1 באוקטובר, הגישה הראשונה של התוקף התרחשה ב-21 בספטמבר, והפעילות הזדונית זוהתה למחרת. הארגון דיווח שהכניסה התבצעה דרך שתי חולשות יום אפס ב-Zammad, מערכת לניהול פניות תמיכה. החקירה עדיין נמשכת.
בתיק החולשות הנלווה מתוארות חולשה המאפשרת השתלטות על חיבור משתמש שמובילה להרצת קוד מרחוק, וחולשה המאפשרת העלאת הרשאות מקומית. תנאי הניצול תלויים בגרסה ובסביבה. ארגון שמשתמש ב-Zammad צריך לבדוק את ההנחיות העדכניות מול ההתקנה שלו; אין להסיק שכל התקנה חשופה באותה צורה.
הלקח שאנחנו מציעים לבחון הוא היקף בדיקות האבטחה של מערכות התמיכה. הפרסום אינו מאפשר לקבוע שמבדק מוקדם היה מגלה את החולשות, ואין בו בסיס לשפוט אילו בדיקות נערכו בארגון לפני הפריצה. אפשר, לעומת זאת, להשתמש בו כדי לבדוק אצלנו שאלה פשוטה: האם אנחנו יודעים מה תהיה המשמעות העסקית של גישה לא מורשית למערכת התמיכה, והאם ניסינו לבחון זאת בתנאים מבוקרים?
מתחילים במה שמערכת התמיכה מכילה
לפני הזמנת מבדק, מומלץ לשבת עם מנהל התמיכה ועם מי שאחראי על המערכת ולמפות את המידע שעובר בה. בדקו אם נשמרים בפניות מסמכים של לקוחות, צילומי מסך, פרטי תשתית או קבצים שנשלחו לצורך טיפול בתקלה. זו רשימת שאלות לבדיקה בארגון שלכם, ולא תיאור של המידע שנחשף באירוע DIVD. המיפוי יעזור להחליט אילו תרחישים חשוב לבדוק ומה אפשר להדגים באמצעות נתוני דמה.
בהמשך, רשמו אילו סוגי משתמשים פועלים במערכת ומה כל אחד אמור לראות. לקוח, נציג תמיכה ומנהל צוות עשויים להזדקק להרשאות שונות. למשל, אפשר להגדיר תרחיש שבו לקוח מנסה לצפות בפנייה שאינה שייכת לו, ולבדוק שההגבלה נאכפת גם בעת פתיחת קובץ מצורף. את התרחיש יש להתאים למבנה המערכת ולבצע רק במסגרת ההרשאה שניתנה לבדיקה.
בסוף המיפוי צריכה להיות הסכמה עסקית ברורה על הגבולות. אם צוות התמיכה עצמו אינו בטוח מי אמור לקבל גישה למסמך מסוים, כדאי להסדיר זאת לפני המבדק. אחרת, גם ממצא טכני מדויק עלול להיתקל בדיון ארוך בשאלה אם ההתנהגות שנמצאה היא תקלה או תכונה שנועדה להקל על העבודה.
בודקים גם את החיבורים למערכות אחרות
היקף הבדיקה צריך להתייחס לחיבורים שהארגון מפעיל בפועל. מומלץ לברר אם מערכת התמיכה מחוברת לדואר, למערכת ניהול לקוחות, לשירות הזדהות או לאחסון קבצים. לכל חיבור רשמו איזה מידע עובר בו ובאיזו הרשאה. המטרה היא לבחור תרחישים רלוונטיים לסביבה שלכם, בלי להניח שכל חיבור הוא חולשה ובלי להרחיב את הבדיקה למערכות שלא אושרו.
נניח שמערכת תמיכה משתמשת בחשבון שירות לצורך גישה למסמכים. בתרחיש בדיקה מוצע, הצוות יבחן אם ההרשאות של החשבון מוגבלות לתיקייה הנדרשת לעבודה. אם החשבון מגיע למידע נוסף, צריך לברר מה מאפשר זאת ומה תהיה ההשפעה של שינוי ההרשאות. זהו תרחיש לדוגמה, לא ממצא מחקירת DIVD. ההפרדה הזאת חשובה כדי שהדיון באירוע אמיתי לא יהפוך לרשימת טענות על פרטים שלא פורסמו.
כאשר ספק חיצוני מנהל חלק מהסביבה, הגדירו מי רשאי לאשר בדיקה ומי אחראי לתיקון. בקשו שהצעת העבודה תציין גם מה נשאר מחוץ להיקף ומה המשמעות של ההחרגה. כך אפשר להבין מראש אם המבדק יענה על השאלה העסקית, או שצריך להשלים אותו בבירור מול הספק לגבי בקרות שאינן נגישות לצוות הבדיקה.
מגדירים מה רוצים ללמוד מהמבדק
כדאי להגיע לשיחת התיחום עם שאלות שאפשר לענות עליהן. לדוגמה: האם לקוח יכול להגיע למסמכים של לקוח אחר, האם נציג תמיכה יכול לבצע פעולה שמותרת רק למנהל, והאם חשבון שירות יכול לגשת למידע מעבר לצורך שהוגדר לו. השאלות האלה הן הצעה לתכנון, ויש לבחור מתוכן רק את מה שמתאים למערכת. הן נותנות לצוות הבדיקה יעד ברור ולבעל המערכת דרך להבין את התוצאות.
במדריך OWASP לבדיקות אבטחת יישומי רשת מודגש הצורך לשלב כלים אוטומטיים עם בדיקה שמבינה את ההקשר של היישום. OWASP הוא Open Worldwide Application Security Project, מיזם פתוח לאבטחת יישומים. בהתאם לגישה הזאת, מומלץ לבקש פירוט של התרחישים הידניים ושל חשבונות הבדיקה הנדרשים, לצד הסריקות המתוכננות. רשימת כלים לבדה אינה מתארת אילו שאלות ייבחנו.
חשוב להסכים גם על גבולות הביצוע: סביבה, חלון זמן, אנשי קשר ומידע שמותר להשתמש בו. בקשו שהדוח יפריד בין פעולה שנבדקה ונחסמה לבין פעולה שלא נבדקה בגלל מגבלה. ההבדל הזה עוזר למנוע מסקנה רחבה מדי מתוך בדיקה מוגבלת, ולתכנן השלמות כשאין אפשרות לכסות את כל התרחישים בהתקשרות הנוכחית.
קובעים איך מטפלים בתוצאות
עוד לפני תחילת העבודה, מומלץ לקבוע מי יקבל ממצא דחוף ומי יחליט על הטיפול בו. אם הבדיקה מצביעה על חשיפה של מסמכים, למשל, כדאי שיהיה ברור מי מוסמך לצמצם גישה ומה צריך לבדוק לפני השינוי. ההחלטה תלויה בסביבה ובפעילות העסקית; המבדק צריך לספק ראיות שיאפשרו לקבל אותה, בלי להפוך את מספר הממצאים למדד היחיד להצלחת העבודה.
לכל ממצא מהותי בקשו תיאור של התנאים שבהם התגלה, המידע או הפעולה שהיו נגישים והמלצה שאפשר להעביר לגורם המטפל. לאחר התיקון, הגדירו איך תיבדק התוצאה. בתרחיש של הרשאות, למשל, כדאי לוודא שהגישה הלא רצויה נחסמה ושמשתמש מורשה עדיין יכול לבצע את עבודתו. זו דרך מעשית לחבר בין טיפול טכני לבין התוצאה העסקית שלשמה הוזמנה הבדיקה.
אם עולה חשד לפריצה שכבר התרחשה, יש צורך בהערכת מצב ובתגובה לאירוע. אין להסתפק בהזמנת מבדק עתידי או להניח שתיקון חולשה מסביר מה קרה לפניו. ברמה הניהולית, מומלץ לשמור בנפרד את מצב הטיפול בממצאי הבדיקה ואת מצב בירור האירוע, כדי שכל החלטה תתבסס על המידע המתאים ועל הגורם המקצועי שמטפל בה.
כיצד Cybecs מסייעת במבדקי חדירה
Cybecs מבצעת מבדקי חדירה ליישומי רשת, לממשקי תכנות יישומים המכונים API, למובייל, לענן ולרשתות פנימיות וחיצוניות. במסגרת בחינת שירות מבדקי החדירה של Cybecs, אפשר להתחיל ממערכת התמיכה ומהתהליכים שהארגון מבקש לבדוק, ולברר אילו תחומי בדיקה מתאימים לסביבה הזאת.
כדי למקד את השיחה, כדאי להכין רשימת מערכות, סוגי משתמשים וחיבורים לספקים, ולתאר את המידע שחשוב להגביל את הגישה אליו. ציינו גם אילו רכיבים נמצאים באחריות הארגון ואילו מנוהלים בחוץ. כך אפשר לתאם את מטרת העבודה ואת היקפה על בסיס צורך ממשי, ולזהות מראש שאלות שדורשות תיאום נוסף.
שאלות נפוצות על בדיקות חדירה
האם צריך לבדוק גם מערכת שנרכשה מספק
כדאי לבחון את הסיכון ואת חלוקת האחריות. חלק מהבדיקה עשוי להתמקד בהגדרות ובחיבורים שבשליטת הארגון, וחלק אחר יחייב תיאום עם הספק. יש להסדיר הרשאה מתאימה לפני ביצוע פעולות בדיקה.
האם מבדק מגלה כל חולשת יום אפס
מבדק מוגבל בזמן, בהיקף ובגישה שניתנה לצוות. הוא עשוי לחשוף חולשות שלא היו מוכרות, אך אין להסיק מכך שיגלה כל חולשה. גם במקרה המתואר כאן אין בסיס לקבוע מה היה מתגלה בבדיקה מוקדמת.
מה כדאי להכין לפני שיחת התיחום
הכינו תיאור קצר של המערכת, סוגי המשתמשים, המידע הרגיש והחיבורים לשירותים אחרים. הוסיפו שאלות עסקיות שתרצו לקבל עליהן תשובה ומגבלות תפעוליות שצריך להביא בחשבון. אין צורך להעביר מידע רגיש או סיסמאות כדי לפתוח את השיחה.
הצעד הבא בתכנון הבדיקה
פתחו את רשימת המערכות הכלולות במבדק הבא ובדקו אם מערכת התמיכה מופיעה בה. אם היא חסרה, בררו מי אחראי עליה, איזה מידע היא מחזיקה ומה הסיבה להחרגה. זו נקודת פתיחה ממוקדת לשיחה על היקף הבדיקה, שתעזור לוודא שהעבודה המתוכננת עונה על הסיכון שחשוב לארגון לבחון.