→ חזרה לבלוג
אבטחת מידע

AMD סירבה לשלם פרס על פגיעות אבטחה קריטית שאיחרה לתקן

13 ביוני 20264 דק' קריאה
AMD סירבה לשלם פרס על פגיעות אבטחה קריטית שאיחרה לתקן

כשתיקון מגיע, אבל הפרס לא

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

124 ימים: מה משמעות הזמן הזה בעולם האבטחה

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

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

תוכניות Bug Bounty: כלי חשוב עם בעיה מבנית

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

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

המשמעות לארגונים שמסתמכים על תוכנת צד שלישי

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

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

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

שאלות נפוצות

מה היא תוכנית Bug Bounty ולמה היא חשובה?

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

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

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

מהי הסכנה שבמנגנון עדכון אוטומטי פגיע?

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

מה הסיכון לארגון כשספק מאחר בתיקון אבטחה?

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

כיצד ארגון יכול להתגונן בסביבה עם רכיבי צד שלישי פגיעים?

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

#Bug Bounty#AMD#אבטחת מידע#חולשות אבטחה#Vulnerability Disclosure#עדכוני תוכנה#סייבר