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

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

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

מתחילים מהחלטה שאפשר לתאר

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

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

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

מתרגמים את השאלה להיקף שניתן לבדוק

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

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

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

מגדירים מראש מה ייחשב תשובה מספקת

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

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

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

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

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

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

המכון הלאומי האמריקאי לתקנים ולטכנולוגיה (NIST) מציע במדריך ‎SP 800-115‎ לתכנן את ההערכה ולתעד כללי עבודה מוסכמים, לרבות היקף, מגבלות, סיכונים ותיאום. זהו מדריך מקצועי, ולא הוכחה שכל סעיף בו הוא חובה החלה על כל ארגון. ההמלצות כאן דורשות התאמה למערכת, להתקשרות ולדרישות החלות עליה. מדריך NIST ונספח כללי העבודה.

מבקשים דוח שמשרת את מי שצריך לפעול

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

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

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

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

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

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

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

מתכננים גם את היום שאחרי הדוח

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

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

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

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