מדיניות התוכנית היא חיונית לכל VDP, ויש לבנות אותה בזהירות. מדיניות התוכנית היא הדבר הראשון שחוקרי אבטחה רואים כשהם משתתפים בתוכנית VDP. היא קובעת את הטון של התוכנית, מגדירה ציפיות ומגדירה את המחויבות שלכם לחוקרים שבוחרים להשתתף.
איך ליצור ולארח את מדיניות התוכנית שלכם
ההנחיות הבאות יעזרו לכם לנסח את מדיניות התוכנית של VDP. מדיניות התוכנית היא בדרך כלל באורך 1-3 דפים בלבד, ובדרך כלל כוללת את הנושאים הבאים:
- הבטחה של חוקר
- הנחיות לבדיקה
- היקף התוכנית
מדיניות התוכנית צריכה להיות זמינה לכל החוקרים הפוטנציאליים. אם אתם מתכננים להשיק באופן פרטי את ה-VDP רק למספר קטן של חוקרים שהוזמנו, מדיניות התוכנית צריכה סוג של בקרת גישה כדי שתהיה זמינה לחוקרים שהזמנתם, אבל מוגבלת לכולם. בנוסף, החוקרים זקוקים לדרך שבה יוכלו לשלוח דוחות, כמו טופס אינטרנט או כתובת אימייל חלופית שמקושרת למערכת כרטיסים לצורך מעקב אחר הדוחות. חשבו על זה בזמן הגדרת המשאבים באינטרנט של ה-VDP.
בדרך כלל, פלטפורמות של צד שלישי לגילוי נקודות חולשה ולשפע על באגים מספקות יכולות כמו:
- דרך ליצור, לערוך ולפרסם מדיניות
- גישה לאמצעי הבקרה ליצירת תוכנית פרטית
- הזמנה אוטומטית של האקרים בקצב נוח
- פונקציונליות של תיבת הדואר הנכנס שמאפשרת עיבוד דוחות נכנסים
פלטפורמות של צד שלישי מציעות גם מגוון שירותי ייעוץ כדי להקל על תהליך היצירה וההשקה של VDP. בדרך כלל פלטפורמות ושירותי ייעוץ של צד שלישי כרוכים בתשלום. כדי להחליט מהי הדרך הטובה ביותר להתקדם הלאה, כדאי להביא בחשבון את העלויות והיתרונות של שימוש בגורמי צד שלישי לעומת בנייה וניהול של התוכנית בתוך הארגון.
כדי לקבל רעיונות נוספים לגבי הפרטים שצריך לכלול במדיניות התוכנית, תוכלו לקרוא את המסמך "A Framework for a Vulnerability Disclosure Program for Online Systems" (מסגרת של תוכנית לגילוי נקודות חולשה למערכות אונליין).
בעלי עניין במדיניות התוכנית
כשאתם מגבשים את מדיניות התוכנית, חשבו איך לעבוד עם בעלי העניין. צוותים שונים עשויים לתת לכם משוב על שיקולים שעלינו להעמיק את המדיניות שלכם.
| בעל עניין | שיקולים |
|---|---|
| משפטי |
|
| IT |
|
| הנדסה |
|
| PR |
|
| אבטחה |
|
הבטחה של חוקרים
ההבטחה של החוקר מסבירה את המחויבויות של הארגון לחוקרים משתתפים, לפעול בתום לב ולפעול לפי הנחיות הבדיקה המפורטות במדיניות. לדוגמה, מחויבות להגיב לכל דוחות האבטחה הנכנסים במסגרת זמן ספציפית, וכן למסור החלטות לגבי אילו דיווחים על נקודות חולשה יתקבלו ותוקנו.
דוגמה:
<שם הארגון> מחויב לעבוד עם חוקרי אבטחה כדי לזהות ולתקן נקודות חולשה במערכות ובשירותים שלנו. כל עוד אתם פועלים בתום לב ומצייתים להנחיות המפורטות במדיניות הזו, נעשה כמיטב יכולתנו להתחייב לדברים הבאים:- מתן תגובה ראשונית לדוח נקודות החולשה תוך שלושה ימי עסקים
- להחליט אם לאשר את הדיווח על נקודות החולשה (בכוונתנו לתקן אותו) או לדחות אותו (לזהות את הדיווח כחיובי שגוי או כסיכון מקובל) בתוך עשרה ימי עסקים.
- עדכונים לגבי ההתקדמות לתיקון הדוחות שאנחנו מקבלים מכם
שימוש בשפה של נמל מבטחים במדיניות התוכנית עוזר להבטיח לחוקרים שלא יינקטו נגדם צעדים משפטיים לצורך בדיקה של המערכות שלכם, כל עוד הן פועלות בתום לב ובהנחיות המפורטות במדיניות.
הנחיות לבדיקה
בהנחיות הבדיקה מתוארות בדיקות האבטחה שחלות במסגרת ה-VDP, וגם בדיקות שלא כלולות בהיקף שחוקרים צריכים להימנע ממנו. אם יש סוגים ספציפיים של נקודות חולשה שהייתם רוצים שהחוקרים יתמקדו בהן, כדאי להדגיש אותן.
דוגמה:
כשמבצעים בדיקות אבטחה, צריך לפעול בהתאם להנחיות הבאות:
- בדקו רק את החשבונות והנתונים שלכם (למשל, יוצרים חשבונות לבדיקה). אם זיהיתם נקודת חולשה שעלולה להוביל לגישה לנתונים של משתמשים אחרים, חשוב שתבדקו איתנו לפני שתתחילו לבדוק את הנושא לעומק.
- אם ניגשתם בטעות לנתונים של משתמשים אחרים במסגרת הבדיקה, עליכם להודיע לנו ולא לאחסן נתוני משתמש כאלה.
- אין לבצע בדיקות שמובילות למצבים של התקפת מניעת שירות (DoS) או לפגיעה באיכות של שירותי הייצור שלנו.
- התוכנית הזו לא כוללת הנדסה חברתית. אין לנסות להנדס חברתית את הארגון או את המשתמשים שלנו.
אנחנו מתעניינים במיוחד בסוגי נקודות החולשה וההשפעות הבאים:
- ביצוע קוד מרחוק
- XSS שהתוצאה שלו היא גישה למידע אישי רגיש (למשל פרטי סשן)
- החדרת SQL שמובילה לגישה למידע רגיש או לפונקציונליות
- ליקויים בלוגיקה עסקית שמובילים לגישה למידע רגיש או לפונקציונליות
אנחנו פחות מעוניינים בסוגים הבאים של נקודות החולשה, יש סיכוי גבוה יותר ש
ייפסלו כתוצאות חיוביות כוזבות או כסיכונים קבילים:
- היעדר כותרת X-Frame-Options בדפים ללא פונקציונליות שמשתנה
- תוצאות סורק אוטומטי לא מאומתות
- בעיות שלא סביר שניתן לנצל ו/או שאין להן השפעה מציאותית על אבטחה
היקף
ההיקף מגדיר את הנכסים שהחוקרים יכולים לבדוק בהשוואה אליהם, וכן את הנכסים שלא נחשבים כחלק מה-VDP. צריך לבחון בקפידה את ההיקף ולוודא שהוא רחב ככל האפשר, בלי להעמיס על הצוות. ככל שתהיו מוכנים להשקיע יותר, כך תגדל הסבירות שתגלו מעורבות מחוקרי אבטחה. עם זאת, לא כדאי להרחיב את ההיקף כך שהצוות לא יוכל לעמוד בקצב של הדוחות שיתקבלו. התחילו עם כמה נכסים בהיקף ההרשאות. הרחב את ההיקף בהתאם להבנה טובה יותר של נפח הדוחות שתקבל. לפני שפותחים את VDP לציבור עם הזמן, כדאי לוודא שהכל כלול.
איך להגדיר את ההיקף במדיניות התוכנית? כדאי להוסיף פרטים על כל נכס או תחום, כדי לעזור לחוקרי אבטחה לדעת מה חשוב לכם והיכן כדאי למקד את המאמצים. תוכלו גם לצרף טיפים לבדיקה בטוחה של הנכסים. לדוגמה:
| נכס | mail.example.com |
|---|---|
| התיאור | הדומיין הראשי שבו משתמשים יכולים לגשת לאימייל. |
| נקודות חולשה והשפעות מעניינות |
|
| בעיות שככל הנראה יידחו |
|
| הנחיות בדיקה | יש לבצע את הבדיקה רק עבור חשבונות שבבעלותכם או שיש לכם הסכמה מפורשת לבצע בדיקה נגדם. כשיוצרים חשבונות בדיקה, צריך לכלול את הכיתוב "vdptest" במקום כלשהו בשם המשתמש. אפשר ליצור חשבונות לבדיקה בכתובת mail.example.com/new. |
זהו פירוט די מפורט. לחלופין, אפשר לכלול רשימה פשוטה של נכסים בהיקף הרשאות שלא נכללות בהיקף ההרשאות:
כולל
- mail.example.com
- example.com
לא בטווח
- blog.example.com
שימוש תמ"ד במקור
יש צורך במשאבים מסוימים לפני השקת VDP. תצטרכו את המשאבים הבאים:
- בדיקת דיווחים נכנסים על נקודות חולשה
- תקשורת עם האקרים
- איתור בעלים של נכסים ומילוי באגים
- תיקון באגים
- ניהול נקודות חולשה / מעקב אחרי תיקון
בדיקה חוזרת של בעלי העניין העיקריים
אם עדיין לא עשיתם זאת, מומלץ לחזור על השיחות עם בעלי עניין מרכזיים שאיתם שוחחתם קודם על ה-VDP, כדי לוודא שהם מתאימים ללוח הזמנים של השקת הווריאנט, ולהכין את המשאבים הנחוצים להשקה. לדוגמה, יכול להיות שתרצו לשתף פעולה עם בכירים בתחום מהנדסי התוכנה כדי להבטיח שהצוותים שלהם יהיו מוכנים לעלייה פוטנציאלית של באגים באבטחה בשבועות הראשונים שלאחר ההשקה. בצוות האבטחה, חשוב לוודא שהתראות החירום במערכות הזיהוי והתגובה שלכם מודעים לתאריך ההשקה של VDP, ולשקול להקצות יותר זמן ומשאבים לשעת התחלת הבדיקה. בנוסף, תצטרכו להקים צוות שיעזור לכם לתמוך בתפעול היומי של VDP.
פיתוח הצוות
כדי להריץ VDP נדרשת כמות לא מבוטלת של עבודה תפעולית שמבוססת על הפרעות. אם תנסו לבדוק כל דיווח על פרצת אבטחה, לאמת אותו ולהגיב עליו, וגם לדווח על כל באג, לעקוב אחרי הסטטוסים ולעדכן את החוקרים בעצמכם, אתם עלולים להגיע למצב של שחיקה. גם אם אין לכם צוות אבטחה גדול, כדאי למצוא מתנדבים עם כוונות אבטחה שיעזרו לכם לבנות צוות שיעזור לכם להפעיל ולהפעיל את ה-VDP. עדיין כדאי להכין "בעלים" או "מוביל" של תיאור הרכב, שבסופו של דבר יהיה אחראי להצלחתו, אבל יהיה לכם גם צוות שיתמוך במנהיג הזה.
בניית לוח זמנים במצב פעיל
ברגע שיש לכם משאבים מתאימים ומוכנים לעזור ל-VDP, מומלץ לבנות לוח זמנים ייעודי. אפשר ליצור את הדוח איך שרוצים, אבל רוטציה שבועית היא די נפוצה. כשנמצאים בתפקיד במהלך השבוע, באחריותכם:
- Triage - בדיקת דיווחים נכנסים על נקודות חולשה
- ניהול נקודות חולשה – קידום נקודות חולשה קיימות
- בודקים את הבאגים שנשלחו מהשבועות האחרונים בתפקיד, כדי לוודא שהתיקון מתבצע בהתאם לסטנדרטים שלכם למידת החומרה וללוחות הזמנים לתיקון.
- כדאי להיעזר בטיפים שמוצאים כדי לשכנע את הבעלים לעבוד על הבאגים האלה
- תקשורת – מתן עדכונים לחוקרי אבטחה על דוחות קיימים
- יכול להיות שחוקרים יבקשו באופן יזום עדכונים לגבי דוחות קיימים, ויבקשו מכם לשלוח תשובה לפי הצורך
- אם נקודות החולשה תוקנו, דווחו על כך לחוקרים כדי שהם ידעו שהעבודה הקשה שלהם הובילה לשינוי חיובי בארגון. תוכלו גם לכלול שפת תבנית כדי לבקש מהחוקר לעדכן אם החמצתם משהו בתיקון, או אם ניתן לעקוף את התיקון בדרך כלשהי.
בהתאם למספר הדיווחים שאתם מקבלים, המורכבות של הדוחות האלה והכישורים והידע של האדם המבצע, יכול להיות שנמשכת כמה שעות עד שבוע שלם. כמה טיפים לסבב מוצלח של פגישות:
- חשוב לוודא שהצוות שלכם מוכן להתחבר ולתמוך במשמרות בשבוע הכבד במיוחד.
- חשוב לנהל תהליך מסירה טוב. אם יש בעיות שכרוכות בטיפול מיידי באדם הבא בתפקיד, כדאי לכתוב כמה הערות מסירה או לנהל שיחה פעילה בסוף השבוע.
- יצירת תזמון אוטומטי כדי להבטיח שכולם ידעו מתי הם נמצאים. זו יכולה להיות משימה פשוטה כמו יצירת רשומות חוזרות ביומן לכל אחד מהם.
- במיוחד לקראת תחילת ה-VDP, חשוב לבדוק היטב עם האדם שבתפקידו לוודא שהשבוע שלו חל, ולבדוק אם הוא צריך עזרה. אם יש לכם יותר משאבים זוטרים בסבב, כדאי להיעזר במשאבים מבוגרים רבים יותר כדי לוודא שהם מרגישים בנוח ולשאול שאלות.
- נהלו תהליך גמיש להחלפת שבועות. במצב חירום, מישהו עלול לצאת לחופשה בשבוע, לצאת לחופשה וכו'. במצב כזה, כדאי לעודד את הצוות להחליף שבועות לפי הצורך כדי להתאים את לוח הזמנים של כולם.
- ליצור 'תקציר' לגבי המשימות שצריך לעמוד בהן, כולל תיעוד של הפעולות שצריך לבצע.
החליטו על שימוש פנימי לעומת צד שלישי
עד כה, רוב ההנחיות התבססו על הבנייה והניהול של ה-VDP באופן פנימי. יש מגוון פלטפורמות ושירותי ייעוץ שיכולים לעזור לכם ליצור ולהפעיל VDP. צדדים שלישיים אלו בדרך כלל כרוכים בעלות, אך הם יכולים להדריך אתכם איך ליצור, להפעיל ולהפעיל את ה-VDP. בחלק מהם גם יש שירותי מיון כדי לבדוק את הדיווחים שמתקבלים על נקודות החולשה שהתקבלו, לטפל בתקשורת עם האקרים ולהעביר דיווחים תקפים רק לצוות שלכם. ההחלטה אם לפתח את התהליך הזה באופן פנימי או באמצעות פלטפורמה של צד שלישי תלויה בדרישות ובמשאבים הזמינים. אם יש לכם תקציב גדול אבל מעט עובדים, כדאי להיעזר בגורם צד שלישי כדי להפעיל את התוכנית. אם זה ההיפך, יכול להיות שכדאי להשקיע את הזמן בפיתוח התוכנה בעצמכם.
קבלת דוחות
אם תחליטו להשתמש בפלטפורמה של צד שלישי, להאקרים צריכה להיות אפשרות לשלוח לכם דוחות ישירות. אם אתם יוצרים את התוכנית בעצמכם, תצטרכו ליצור אותה בעצמכם. זו יכולה להיות כתובת אימייל שיוצרת באופן אוטומטי פנייה או באג בכלי למעקב אחר בעיות (למשל security@example.com) או טופס אינטרנט עם שדות טופס נדרשים שמקושר לאותו דף של מדיניות התוכנית או באותו הדף. בכל דרך שתבחרו, זו ההזדמנות הכי טובה שלכם להודיע להאקרים באיזה פורמט תרצו לקבל את הדוחות. חשוב לזכור: לא תמיד אפשר לבקש מהאקרים לשלוח דוחות בפורמט מסוים, אבל לא מזיק לבקש. לפניכם דוגמה למה שאפשר לבקש בטופס לשליחת דוח:
Title: [יש להוסיף תיאור בשורה אחת של הבעיה, למשל "XSS in
mail.example.com
תוצאות בגניבת פעילות באתר"]
1.
2.
3.
תרחיש התקפה והשפעה: [איך אפשר לנצל את זה? מהי ההשפעה של
הבעיה על האבטחה?]
עצות לתיקון: [אופציונלי, אם יש לכם עצות לגבי האופן שבו אפשר לתקן או לתקן את הבעיה, מוסיפים אותה כאן.]