כל כמה זמן צריך לבצע מבדק חדירות? המדריך המעשי

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

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

מהי התדירות הבסיסית המומלצת?

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

חברות קטנות וסטארטאפים

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

חברות SaaS וטכנולוגיה B2B

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

פינטק, בריאות, קמעונאות ותשתיות קריטיות

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

ארגונים גדולים ואנטרפרייז

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

מה אומרים תקני הציות?

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

PCI DSS v4.0.1

זהו התקן עם הדרישות הברורות ביותר בנושא תדירות. סעיף 11.4 ב-PCI DSS v4.0.1^[1] מחייב מבדק חדירות שנתי לפחות, ובנוסף – מבדק אחרי כל שינוי משמעותי בסביבת נתוני האשראי (CDE). אם הארגון משתמש ב-network segmentation כדי לצמצם את היקף הציות, בדיקת ה-segmentation עצמה חייבת להתבצע כל 6 חודשים. כלומר, ארגון שמעבד נתוני תשלום לא יכול לצאת ידי חובה עם מבדק שנתי בלבד.

ISO 27001

תקן ISO 27001^[2] אינו מגדיר תדירות ספציפית לביצוע מבדקי חדירות. במקום זאת, הוא דורש ממסגרת ניהול סיכונים לקבוע את לוח הבדיקות בהתאם לרמת הסיכון של כל נכס. בפועל, ארגונים מוסמכי ISO 27001 מבצעים מבדק שנתי לפחות, אבל הדגש בתקן הוא על הוכחת תהליך – לא על תאריך בלוח השנה. גרסת ISO/IEC 27001:2022 הוסיפה דגש מוגבר על בדיקת אבטחה כחלק מניהול סיכוני המידע השוטף.

SOC 2

גם SOC 2 אינו מגדיר תדירות חובה, אבל מבקרי SOC 2 מצפים לראות עדויות לבדיקות אבטחה עצמאיות. חברות שעוברות ביקורת SOC 2 Type II – שמכסה תקופה של 6 עד 12 חודשים – צריכות שהמבדק ייכלל בתוך אותה תקופה. אם הדוח ישן מ-12 חודשים, ייתכן שהמבקר יסמן את הנושא כפגם בבקרות.

HIPAA ו-GDPR

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

טריגרים שמחייבים בדיקה מיידית

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

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

למה ה-Retest הוא חלק בלתי נפרד מהמבדק

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

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

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

שגיאות נפוצות בניהול תדירות מבדקי החדירות

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

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

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

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

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

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

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

שלושה גורמים עיקריים צריכים להשפיע על ההחלטה:

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

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

דרישות הציות. ברגע שהארגון מחויב ל-PCI DSS, ISO 27001, SOC 2 או רגולציות דומות – יש בסיס מינימלי שנקבע מבחוץ. אבל כאמור, זוהי הרצפה – לא התקרה. ארגון שמבצע מבדק "רק כדי לסמן V" מפספס את עיקר הערך שמבדק חדירות יכול להציע.