תוֹכֶן
- רק העובדות
- אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
- מתייחסים להשפעה?
- זמן לשנות את המערכת?
מקור: BrianAJackson / iStockphoto
להסיר:
הגיע הזמן לוודא את האופן בו אנו חושבים על הערכת סיכון לרכיבי קוד פתוח.
פיתוח מערכת להערכת כמה ברצינות קהילת פיתוח התוכנה צריכה לקחת פגיעויות היא אתגר, בלשון המעטה. הקוד נכתב על ידי בני אדם, ותמיד יהיו בו פגמים. השאלה אם כן, אם אנו מניחים ששום דבר לעולם לא יהיה מושלם, היא כיצד אנו מסווגים את המרכיבים בצורה הטובה ביותר לפי הסיכון שלהם באופן המאפשר לנו להמשיך לעבוד באופן פרודוקטיבי?
רק העובדות
אמנם ישנן גישות רבות ושונות שאפשר לנקוט בהן כדי להתמודד עם בעיה זו, לכל אחת מהן יש הצדקה תקפה משלהן, נראה שהשיטה הנפוצה ביותר מבוססת על מודל כמותי.
מצד אחד, שימוש בגישה כמותית כדי לשפוט את חומרת הפגיעות יכול להיות שימושי בכך שהיא יותר אובייקטיבית ומדידה, המבוססת אך ורק על הגורמים הקשורים לפגיעות עצמה.
מתודולוגיה זו בוחנת איזה סוג של נזק עלול להתרחש אם יש לנצל את הפגיעות, בהתחשב באיזו שימוש נרחב משתמשים ברכיב, בספריה או בפרויקט בכל ענף התוכנה, כמו גם גורמים כמו איזו גישה היא יכולה לתת לתוקף הרס הרס אם הם ישתמשו בו כדי להפר את היעד. גורמים כמו יכולת ניצול פוטנציאלית קלה יכולים למלא כאן תפקיד גדול בהשפעה על הניקוד. (למידע נוסף בנושא אבטחה, בדוק את Cybersecurity: כיצד מקדמות חדשות מביאות איומים חדשים - וההפך.)
אם אנו רוצים להסתכל ברמה מאקרו, הפרספקטיבה הכמותית בוחנת כיצד פגיעות עלולה לפגוע בעדר, תוך התמקדות פחות בנזק שעלול להיפגע על החברות שנפגעו בפועל מההתקפה.
מסד הנתונים הפגיעות הלאומי (NVD), אולי מסד הנתונים הפגיעויות הידוע ביותר, נוקט בגישה זו הן עבור גרסאות 2 ו -3 - מערכת ניקוד הפגיעות המשותפת שלה (CVSS). בדף שלהם המסביר את הערכים שלהם להערכת פגיעויות, הם כותבים על השיטה שלהם כי:
המודל הכמותי שלה מבטיח מדידה מדויקת שניתנת להחזרה תוך שהיא מאפשרת למשתמשים לראות את מאפייני הפגיעות הבסיסיים ששימשו להפקת הציונים. לפיכך, CVSS מתאים היטב כמערכת מדידה סטנדרטית לתעשיות, ארגונים וממשלות הזקוקות לציוני פגיעות מדויקים ועקביים.
בהתבסס על הגורמים הכמותיים שמשחקים, ה- NVD מסוגל אז לעלות עם ציון חומרה, שניהם עם מספר בסולם שלהם - 1 עד 10, כאשר 10 הם החמורים ביותר, כמו גם קטגוריות של LOW, MEDIUM ו- HIGH .
אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
אתה לא יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.
מתייחסים להשפעה?
עם זאת, נראה כי ה- NVD עושה מאמץ להימנע ממה שאנחנו יכולים למנות כמדד איכותי יותר לפגיעות, על סמך מידת ההשפעה של ניצול מסוים בגרימת נזק. כדי להיות הוגנים, הם משלבים השפעה ככל שהם מודדים את השפעת הפגיעות על המערכת, תוך התבוננות בגורמים של סודיות, שלמות וזמינות. כל אלה הם אלמנטים חשובים שכדאי לבחון - כמו עם וקטור הגישה הניתן למדידה ביתר קלות, מורכבות גישה ואימות - אך הם אינם חשים במשימת הקשר של ההשפעה בעולם האמיתי כאשר פגיעות גורמת לארגון הפסדים של ממש.
קחו לדוגמא את הפרת אקוויפקס שחשפה את המידע המאפשר זיהוי אישי של כ -145 מיליון איש, כולל פרטי רישיון הנהיגה שלהם, מספרי ביטוח לאומי וקטעים אחרים שעשויים להשתמש בדמויות חסרי מצפון לביצוע פעולות הונאה מאסיביות.
זו הייתה הפגיעות (CVE-2017-5638) שהתגלתה בפרויקט אפאצ'י Struts 2 בו השתמש אקוויפקס באפליקציית האינטרנט שלהם, שאפשרה לתוקפים ללכת בדלת הכניסה ובסופו של דבר להוציא אותה בזרועותיהם מלאות במידע אישי עסיסי. .
בעוד שב- NVD העניקו לו בצדק ציון חומרה של 10 ו- HIGH, החלטתם נבעה מהערכתם הכמותית של הנזק הפוטנציאלי שלה ולא הושפעה מהנזק הנרחב שהתרחש לאחר מכן עם הפרת אקוויפקס.
זו אינה פיקוח על ידי NVD, אלא חלק מהמדיניות המוצהרת שלהם.
ה- NVD מספק "ציוני בסיס" של CVSS המייצגים את המאפיינים המולדים של כל פגיעות. כרגע איננו מספקים "ציונים זמניים" (מדדים המשתנים עם הזמן עקב אירועים חיצוניים לפגיעות) או "ציונים סביבתיים" (ציונים המותאמים אישית כדי לשקף את השפעת הפגיעות על הארגון שלך).
עבור מקבלי ההחלטות, מערכת המדידה הכמותית צריכה להיות חשובה פחות מכיוון שהיא בוחנת את הסיכויים שהיא תפזר נזק בכל הענף. אם אתה מנהל הסמכויות של בנק, אתה צריך להיות מודאג מההשפעה האיכותית שיש לניצול יכול להיות אם הוא משמש לפינוי עם נתוני הלקוח שלך, או גרוע מכך, כסף שלהם. (למדו על סוגים שונים של פגיעויות ב- 5 האיומים המפחידים ביותר בתחום.)
זמן לשנות את המערכת?
אז האם הפגיעות ב- Apache Strusts 2 ששימשה במקרה של אקיפאקס, תקבל דירוג גבוה יותר לאור מידת הנזק שהתברר להיות, או שהופך את המעבר ליותר סובייקטיבי עבור מערכת כמו NVD להמשיך?
אנו נותנים שלמציאת הנתונים הדרושים בכדי להגיע לציון "איכות הסביבה" או "הציון הזמני" כמתואר על ידי ה- NVD, יהיה קשה מאוד, לפתוח את מנהלי צוות ה- CVSS בחינם לביקורת בלתי פוסקת וטון עבודה. עבור NVD ואחרים לעדכון מסדי הנתונים שלהם עם היציאה של מידע חדש.
יש, כמובן, השאלה כיצד יתבצע ציון כזה, מכיוון שמעט מאוד ארגונים עשויים להמציא את הנתונים הדרושים על השפעת ההפרה אלא אם כן נדרשו להם על פי חוק הגילוי. ראינו מהמקרה של Uber כי חברות מוכנות לשלם במהירות בתקווה לשמור שהמידע סביב הפרה יגיע לעיתונות שמא לא יתמודדו עם התנגשות ציבורית.
אולי מה שנחוץ הוא מערכת חדשה שעלולה לשלב את המאמצים הטובים ממסדי הנתונים של הפגיעות, ולהוסיף ציון נוסף משלהם כאשר המידע יתפנה.
מדוע לפתוח ברובד הניקוד הנוסף הזה כאשר נראה כי הקודם עשה את עבודתו מספיק טוב כל השנים?
בכנות, זה מסתכם באחריות לארגונים לקחת אחריות על היישומים שלהם. בעולם אידיאלי, כולם היו בודקים את ציוני הרכיבים שהם משתמשים במוצרים שלהם לפני שהם מוסיפים אותם למלאי שלהם, מקבלים התראות כאשר מתגלות פגיעויות חדשות בפרויקטים שנחשבו בעבר כבטוחים ומיישמות את התיקונים הנחוצים לבד. .
אולי אם הייתה רשימה שהראתה עד כמה הרסניות מסוימות של פגיעויות אלה יכולות להיות עבור ארגון, אז ארגונים עשויים לחוש יותר לחץ לא להיתפס עם רכיבים מסוכנים. לכל הפחות, הם עשויים לנקוט צעדים לביצוע מלאי אמיתי של ספריות קוד פתוח שכבר יש להם.
בעקבות הפיאסקו של אקוויפקס, ככל הנראה יותר ממנהלת אחת ברמת ה- C הייתה מתערבלת כדי לוודא שאין להם את הגרסה הפגיעה של סטרוטס במוצריהם. זה מצער שלקח אירוע בסדר גודל כזה כדי לדחוף את הענף להתייחס ברצינות לאבטחת הקוד הפתוח שלהם.
יש לקוות שלשיעור שלפגיעויות במרכיבי הקוד הפתוח של היישומים שלך יכולות להיות השלכות בעולם האמיתי ישפיעו על האופן בו מקבלי ההחלטות מעדיפים עדיפות לאבטחה, תוך בחירת הכלים הנכונים לשמירה על אבטחת המוצרים שלהם ושל הלקוחות.