בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מחירון מבדק חדירות
מחיר מבדק חדירות תלוי במה שבודקים, בנקודת ההתחלה ובעומק הכיסוי שנדרש. אתר קטן, API עם כמה תפקידים ורשת ארגונית אינם אותו פרויקט, גם אם כולם נקראים פנטסט. בדף זה מוסברים גורמי התמחור והדרך להשוות הצעות עבודה. אין כאן תעריף מספרי קבוע: לקבלת הצעה נדרש תיחום של הסביבה והתוצרים, בלי להסתפק בשם השירות.
למה אין מחיר אחד לכל מבדק?
מספר נכסים הוא רק חלק מההיקף. אפליקציה עם מעט מסכים יכולה לכלול הרשאות מורכבות, כמה ארגונים ותהליכים עסקיים רבים. לעומת זאת, מערכת גדולה עשויה להציג כמה זרימות דומות. העלות מושפעת מזמן הלמידה, ממספר התרחישים, מסוג הגישה ומכמות העבודה שנדרשת לתיעוד ולאימות. כדי לקבל הצעת מחיר שימושית, צריך לתאר את הפונקציות ואת הגבולות. מחיר נמוך או גבוה לבדו אינו מעיד על איכות. יש לברר מה נכלל, מה לא נכלל ואיזה עומק בדיקה הוצע, כדי שההשוואה תתייחס לאותה עבודה.
הגורמים שמשפיעים על היקף ועל עלות
ב-Web וב-API חשובים סוגי משתמשים, הפרדת לקוחות, ממשקים ותהליכים עסקיים. במובייל בוחנים מספר פלטפורמות וגרסאות ואת הכיסוי של שירותי השרת. בתשתיות ובענן נדרשים מיפוי זהויות, משאבים וגבולות גישה. נוסף לכך, זמינות תיעוד וסביבת בדיקה יכולה להשפיע על זמן ההכנה. דרישה לבדיקת קוד, לסקירת תצורה או לתרגיל זיהוי ותגובה משנה את סוג העבודה ולא רק את הכמות. כל אחד מהנושאים צריך להופיע בתיחום. כדאי להימנע מהצעה שמציינת רק מספר ימים בלי להסביר מה אפשר יהיה לכסות במהלכם.
איזה מידע צריך להצעת מחיר מדויקת?
אפשר להתחיל מתיאור המוצר, רשימת נכסים, תפקידים וזרימות מרכזיות. חשוב לציין אם מדובר בסביבת בדיקה או ייצור, אם ניתנים חשבונות ואם קיימת מגבלה על פעולות מסוימות. מועד יעד, שפת דוח וקהל היעד של התוצרים הם פרטים שימושיים. אם יש דרישה מצד לקוח או ביקורת, כדאי להעביר את נוסח הדרישה בלי להניח שכל פנטסט עונה עליה. אין צורך לשלוח סיסמאות או מאגרי מידע לצורך הפנייה הראשונית. אחרי שיחת תיחום אפשר להסכים על ערוץ להעברת החומרים הדרושים ועל הצעת עבודה שמפרטת את התנאים.
איך משווים בין שתי הצעות פנטסט?
ראשית משווים את הנכסים ואת נקודת ההתחלה. אחר כך בודקים כיסוי של תפקידים, זרימות וממשקים, ואת השילוב בין כלי בדיקה לבין עבודה ידנית. יש לברר האם המחיר כולל דוח מפורט, שיחת הסבר ובדיקה חוזרת, וכמה סבבים נכללים אם הוגדרו. הצעה לבדיקת סריקה בלבד אינה שקולה להצעה שמכסה הרשאות ולוגיקה עסקית. גם מגבלות זמן ותפעול צריכות להיות ברורות. ההשוואה מועילה כאשר אפשר להסביר מה מקבלים מכל הצעה ומה תהיה המשמעות של היקף מצומצם יותר, ולא כאשר מסתמכים על שורת המחיר לבדה.
מה עלול ליצור עבודה נוספת?
נכס שלא נכלל בתיחום, תפקיד חדש או שינוי מהותי בגרסה יכולים להצריך הרחבת עבודה. גם סביבת בדיקה שאינה זמינה או חיבור שלא תועד עשויים להשפיע על התכנון. בהצעה כדאי להגדיר איך מטפלים בשינויים ומי מאשר הרחבה. אין להניח שהבדיקה כוללת כל מערכת שמתגלה בדרך. בדיקה חוזרת צריכה לקבל גבולות ברורים: אילו ממצאים נבחנים, באיזו סביבה ובאיזה מועד. אם נדרשת בדיקה מלאה לאחר שינוי משמעותי, היא שונה מאימות תיקון של כמה ממצאים. הגדרה מראש מצמצמת אי הבנות ומאפשרת לתכנן את התקציב ואת זמן הצוותים.
בחירת היקף שמתאים למטרה העסקית
לפני שמצמצמים עבודה כדי לחסוך בעלות, כדאי לזהות מהו הנכס החשוב ומהי השאלה המרכזית. אפשר לעיתים לתכנן בדיקה מדורגת שמתחילה בזרימות קריטיות וממשיכה לתחומים נוספים. צריך לתעד את המגבלות של גישה זו ולא להציג תוצאה חלקית ככיסוי מלא. מבדק נועד לסייע בקבלת החלטות, ולכן חשוב להשאיר זמן לתיקון ולבדיקה חוזרת ולא רק לביצוע הראשוני. שיחת תיחום מסודרת מאפשרת לבחור בין Web, API, ענן ותשתיות, או לשלב אותם לפי הצורך. התוצאה הרצויה היא הצעה שאפשר להבין, להשוות ולבצע.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
כמה עולה מבדק חדירות?
העלות נקבעת לפי היקף, עומק, סביבת בדיקה ותוצרים. ללא תיחום אי אפשר לתת מחיר שמייצג את העבודה. אפשר לפנות עם תיאור מערכת כדי לקבל הצעה מותאמת.
למה לא מופיע מחיר מספרי בדף?
אין כאן טווח מחירים מאושר לפרסום. במקום להציג סכום שאינו מתאים לכל מערכת, הדף מפרט מה משפיע על העלות ואילו פרטים נדרשים להצעה.
האם בדיקה חוזרת כלולה במחיר?
יש לברר זאת בהצעת העבודה. אם היא כלולה, חשוב לדעת את ההיקף, מספר הסבבים והמועד. אין להניח שאימות תיקונים כולל מבדק מלא של גרסה חדשה.
האם מספר כתובות קובע את המחיר?
לא לבדו. תפקידים, תהליכים, זהויות וקשרים בין רכיבים משפיעים על העבודה. שתי סביבות עם אותו מספר כתובות יכולות לדרוש עומק וזמן שונים.
אפשר להתחיל בהיקף מצומצם?
אפשר לתכנן עבודה מדורגת, בתנאי שהמטרות והמגבלות ברורות. יש לזהות תחומים קריטיים ולתעד מה נשאר מחוץ לבדיקה, כדי שלא להציג כיסוי חלקי כמלא.
איך מקבלים הצעת מחיר?
פונים עם תיאור מערכת, סוגי משתמשים, נכסים ומועד יעד. בשיחת תיחום מבררים סביבה, הרשאה ותוצרים. פרטי גישה מועברים רק בערוץ מוסכם בהמשך.