הכנה

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

איתור באגים

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

ניהול נכסים

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

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

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

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

בחירת כלים

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

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

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

המערכת סורקת את ההגדרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תיקון באגים

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

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

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

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

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

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

טיפוח באגים

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

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

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

שם:

בהמשך מוצגת דוגמה לנקודת חולשה שעלולה להיות ברמת חומרה גבוהה:

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

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

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

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

המערכת מחפשת בעלים

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

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

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

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

זיהוי ותגובה

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

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

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

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