הכנה

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

איתור באגים

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

ניהול נכסים

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

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

בדיקת נקודות חולשה בסיסית

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

בחירת כלים

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

• דרישות הארגון שלך
• באיזו מידה כל אחד מהכלים עומד בדרישות האלה
• אם היתרונות של הכלי עולים על העלויות (כספי והטמעה).

אפשר להשתמש בתבנית הדרישות הזו (OpenDocument .ods, Microsoft Excel .xlsx) כדי לבחון כלים שונים לעומת הדרישות שלכם. בתבנית הזו נכללות כמה דרישות לדוגמה, אבל מומלץ לדבר עם צוותי האבטחה, ה-IT וההנדסה כדי לבחון את היכולות הנדרשות. לפני השקת תוכנית לגילוי נקודות חולשה, לכל הפחות, תצטרכו להיות מסוגלים לבצע סריקות של נקודות חולשה בנכסים דיגיטליים חיצוניים (כמו אתרים, ממשקי API, אפליקציות לנייד). כך תוכלו למצוא ולתקן נקודות חולשה שניתנות לגילוי בקלות לפני שתזמינו מומחי אבטחה חיצוניים לבדיקת הנכסים והשירותים האלה.

מתבצעת סריקה

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

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

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

תהליך בדיקת האבטחה

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

קריטריונים לבדיקת אבטחה

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

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

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

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

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

העברת בדיקות אבטחה

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

ביצוע בדיקות אבטחה

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

תיקון באגים

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

ניהול נקודות חולשה

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

הגדרת סטנדרטים של חומרה ולוחות זמנים לתיקון בעיות

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

רמת סיכון	תיאור	ציר הזמן לתיקון	דוגמאות
קריטי	בעיות שמסכנות את המשתמשים שלנו או את העסק שלנו.	בעלים: הבעלים הראשי כדי לוודא שנקודת החולשה תוקנה, יש לזהות אותה בתוך 8 שעות. המשאבים של הדף והשיחות הם לפי הצורך גם מחוץ לשעות הפעילות הרגילות. תיקון: צריך לתקן את הבעיה, או לכל הפחות למזער את הסיכון בתוך 3 ימי עסקים, לכל היותר.	פגיעה במסד נתוני ייצור, כולל כל הרשומות הפיננסיות של המשתמשים. תוקף תוקף מקבל גישה לסודות מסחריים, כמו האלגוריתמים הקנייניים שלנו להשקעה. אירוע פעיל שכולל תוקף שמשפיע על הגישה לרשת הפנימית שלנו או למערכות הייצור הרגישות שלנו.
רחב	בעיות של ניצול יכולות לגרום לנזק משמעותי.	בעלים: צריך לזהות בעלים ראשי תוך יום עסקים אחד. תיקון: תוך 10 ימי עסקים (כשבועיים).	נקודות חולשה שעלולות להוביל לגישה למידע או לפונקציונליות של משתמשים רגישים (למשל, היכולת של כל משתמש לגנוב כסף ממשתמש אחר).
אמצעי הגעה לאתר	בעיות שקשה יותר לנצל או לא לגרום לנזק ישיר.	בעלים: הבעלים הראשי צריך להיות מזוהה תוך חמישה ימי עסקים. תיקון: תוך 20 עד 40 ימי עסקים (כחודש עד חודשיים).	בעיות מאומתות שזוהו על ידי סורקים אוטומטיים, כמו תיקונים לעדכוני אבטחה ללא יתרות ידועות. בעיות שקשורות לחשיפת מידע שככל הנראה יעזרו במתקפות נוספות. בעיות שמגבילות אפשרויות לניצול פוטנציאלי (למשל, ניחושים רציפים של סיסמאות של משתמש).
נמוך	בעיות עם השפעה מינימלית; משמש בעיקר לרישום בעיות ידועות.	אין דרישות לאיתור בעלים או לתיקון במסגרת הזמן שצוינה.	חשיפת מידע שאינה מהווה סיכון סביר, אך אינה חייבת להיות נגישה באופן חיצוני.

באגים

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

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

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

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

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

כותרת: [גבוה] הפניה של אובייקט ישיר לא מאובטח (IDOR) בדפי פרופיל סיכום: התגלה ב-User ID פונקציונליות של דפי פרופיל באפליקציה שלנו, שמאפשרת לכל משתמש לקבל גישה לא מורשית כדי להציג ולערוך פרופיל של משתמש אחר, כולל השם המלא, כתובת המגורים, מספר הטלפון ותאריך הלידה של המשתמש האחר. בדקנו את היומנים ונראה שהבעיה הזו לא תנוצלה עדיין. הבעיה התגלתה בתוך הארגון. שלבי השחזור:

1. לדוגמה, אפשר להגדיר שרת proxy, כמו Burp Suite, כדי ליירט תנועה במכשיר נייד שבו האפליקציה מותקנת.
2. נכנסים לדף הפרופיל ומיירטים את בקשת ה-HTTP המשויכת.
3. צריך לשנות את profileID=###### ל-profileID=000000 (זה משתמש בדיקה) ולשלוח באמצעות בקשת ה-HTTP.
4. האפליקציה תציג את הפרופיל של המשתמש 000000, ותוכלו להציג ולערוך את הפרטים שלו.

תרחיש התקפה / השפעה: כל משתמש יכול להשתמש בנקודת החולשה הזו כדי לראות ולערוך את הפרופיל של משתמש אחר. במקרה הגרוע ביותר, התוקף יכול להפוך את תהליך אחזור פרטי הפרופיל של כל המשתמשים במערכת כולה לאוטומטי. אנחנו עדיין לא חושבים שזו תוצאה של ניצול לרעה, אבל חשוב שנתייחס לכך כבעיה רגילה בחומרה גבוהה. אם נבחין בניצול לרעה, הדבר עלול להוביל לחומרה קריטית. שלבי התיקון: מטמיעים בדיקות בצד השרת כדי לוודא שלמשתמש שמגיש את הבקשה יש גישה להצגה/עריכה של הפרופיל שהתבקש באמצעות הערך של IDID. לדוגמה, אם Alice מחובר ויש לו פרופיל ID 123456, אך אליס זיהתה שהוא ביקש פרופיל ID 333444, הוא אמור לראות שגיאה, וצריך לנסות את הניסיון לגשת לפרופיל של משתמש אחר. מידע נוסף על IDOR ואיך לפתור את הבעיה זמין במאמר החומרים של OWASP בנושא הבאג הזה.

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

מתבצע חיפוש של בעלים

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

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

ניתוח שורש הבעיה

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

זיהוי ותגובה

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

הסיכונים הפוטנציאליים כוללים:

• עומס יתר של התראות: שיטפון של התראות או אותות שנראים כמו התקפות זדוניות, אבל למעשה הם בדיקות רגילות שאושרו על ידי חוקרי אבטחה המשתתפים ב-VDP שלכם. כל כך הרבה רעשים יוצרים שקשה להבחין בין התקפות אמיתיות לבין בדיקות אבטחה לגיטימיות.
• התרעות על התרעות שווא לגבי אירועים: אם בעסק שלכם מתקיימים תהליכים בשעה 02:00 ביום שבת, הם לא יהיו מוכנים להתעורר ולחקור הפרה פוטנציאלית שקשורה לבדיקות אבטחה.
• חסימת חוקרי אבטחה: אם הגדרתם כתובות IP אגרסיביות (מערכות למניעת פריצות) ייתכן שבסופו של דבר תחסום את כתובת ה-IP של אחד מהחוקרים לאבטחת מידע שמנסה להריץ סריקות, בדיקות ידניות וכו' כדי לזהות נקודות חולשה ולדווח עליהן. במיוחד במקרה של VDP, אם חוקר אבטחה נחסם אחרי חמש דקות של בדיקה, הוא עלול לאבד את העניין ולהתמקד בתוכנה של ארגון אחר. כתוצאה מכך, יכול להיות שלכל אחד מהחוקרים בארגון לא תהיה מעורבות בפעילויות מחקר, מה שמגדיל את הסיכון לפרצות אבטחה שלא מזוהות עדיין. אמנם לא כדאי להקטין את מספר ה-IPS שלכם, אבל יש עוד אמצעים שאפשר להשתמש בהם כדי לצמצם את הסיכון לניתוק החוקרים.

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