חשיפה מתואמת של פגיעויות (CVD)
כיצד לדווח על פרצות אבטחה, לקבל אותן ולתאם אותן, עם מדיניות לדוגמה.
חשיפה מתואמת של פגיעויות (Coordinated vulnerability disclosure, CVD) היא מונח בתחום אבטחת המחשבים. היא מתארת כיצד אנשים יכולים לשתף דיווחים על בעיות אבטחה. דוגמאות הן דיווחי באגים, סיכוני חדירה, אזהרות על פריצות, דליפות נתונים, פריצות לאתרי אינטרנט וכדומה.
תרגומים: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文
תוכן עניינים:
- מבוא
- מהי חשיפה מתואמת של פגיעויות?
- שלב 1: דווחו על הבעיה
- שלב 2: הבטיחו אנשי קשר
- שלב 3: פעלו בתום לב
- אמתו הצלחה
- הנחיות
- מקרים מיוחדים
- חשיפה מתואמת של פגיעויות לעומת חשיפה אחראית
- מעקב
מדיניות:
- CERT: מדיניות חשיפת פגיעויות
- GitLab: מדיניות חשיפה אחראית
- Salesforce: מדיניות חשיפה אחראית
- The Atlantic: חשיפה אחראית של פגיעויות אבטחה
- Walmart: מדיניות חשיפה אחראית
- Zendesk: מדיניות חשיפה אחראית
מבוא
מסמך זה מסביר חשיפה מתואמת של פגיעויות בדרכים שעשויות לסייע לאנשים לעבוד יחד.
מטרות המסמך:
לסייע לאנשים שמגלים בעיות אבטחה ורוצים לדווח עליהן.
לסייע לנציגי חברות להבין את הצרכים, המטרות, הפרקטיקות והמקרים המיוחדים של חשיפה אחראית.
לכלול בתיקיית המאגר מדיניות לדוגמה של חשיפה מתואמת של פגיעויות.
נשמח לקבל pull requests, GitHub issues או דוא"ל לכתובת security@joelparkerhenderson.com.
מהי חשיפה מתואמת של פגיעויות?
חשיפה מתואמת של פגיעויות מתארת שלושה שלבים כאשר מישהו מגלה בעיית אבטחה (כגון באג בתוכנה) ורוצה לדווח עליה ליצרן (כגון החברה שמייצרת את התוכנה).
שלבים:
המגלה מדווח על הבעיה ליצרן באופן פרטי ובתום לב.
היצרן מנסה בתום לב להגן על המשתמשים ולטפל בבעיה.
לאחר פרק זמן מוסכם, בעיית האבטחה מפורסמת לציבור.
שלב 1: דווחו על הבעיה
שלב 1 מיועד למגלה: דווחו על הבעיה באופן פרטי ובתום לב.
טוב: המגלה שולח את המידע הרלוונטי ליצרן, למשל בדוא"ל לכתובת הדוא"ל של היצרן לענייני אבטחה (בדרך כלל "security@example.com") או באמצעות טופס בדף אינטרנט באתר היצרן (בדרך כלל "https://www.example.com/security").
רע: פרסום הדיווח בבלוג ציבורי, התראת התקשורת, איומים או ניסיונות למכור את בעיית האבטחה להאקרים וכדומה.
טיפ: המגלה רשאי לבחור להישאר אנונימי; גם היצרן רשאי לבחור להישאר אנונימי.
אם תרצו, המשיכו להיות מודעים לבעיה.
טוב: פתיחת ערוצי תקשורת, מתן מידע המשך או מעקב אחר המצב.
רע: שכחת הבעיה.
טיפ: המגלה רשאי לבחור לעזור או לא, וגם לבחור לשמור על קשר או לא, וכן לשנות את ההסדר אם הנסיבות משתנות.
אם תרצו, חשפו את הבעיה לאחרים.
טוב: להמתין את פרק הזמן שנקבע ואז לפרסם, למשל על ידי פרסום המידע הרלוונטי באתר חדשות אבטחה, יצירת קשר עם חוקרי אבטחה צד שלישי רלוונטיים או הכרזה על הבעיה בכל אתר חברתי ציבורי וכדומה.
רע: אי חשיפת הבעיה לאחרים, אלא אם אתם מרגישים שהדבר יגרום ליותר מסיכון דומה לעצמכם או לאחרים.
טיפ: אם הנסיבות משתנות, למשל מתגלה סיכון גבוה יותר או ניצול פעיל בשטח (in the wild), המגלה רשאי לחשוף את הבעיה לאחרים מוקדם יותר.
שלב 2: הבטיחו אנשי קשר
שלב 2 מיועד ליצרן: ודאו שאנשי הקשר ישימים.
טוב: היצרן מפרסם כתובת דוא"ל ליצירת קשר בנושאי אבטחה (בדרך כלל "security@example.com") ובאופן אידיאלי גם מפתח הצפנה מאובטח לדוא"ל.
טוב: היצרן מפרסם דף אינטרנט ליצירת קשר בנושאי אבטחה (בדרך כלל "https://www.example.com/security") ובאופן אידיאלי הופך את הדף לקל לגילוי, למשל דרך תחתית האתר, מפת האתר והחיפוש.
רע: היצרן אינו מספק כתובת דוא"ל או דף אינטרנט, או אינו הופך אותם לקלים לגילוי.
ודאו את יכולות הצוות.
טוב: היצרן מכשיר את צוות התמיכה מה לעשות אם הם מקבלים פנייה בנושא אבטחה, למשל כיצד להשיב עם פרטי קשר או כיצד להעביר את הפנייה לצוות הפנימי הנכון.
טוב: היצרן מוודא מעת לעת שיכולות הצוות פועלות.
רע: היצרן אינו מכשיר או אינו מוודא.
השיבו למגלה במסגרת לוח הזמנים.
אם המגלה אינו מציין לוח זמנים, השתמשו ביום עסקים אחד, כי זהו תקן התעשייה ושיטת העבודה המיטבית הנוכחית בתעשייה.
אם המגלה שואל שאלות, ענו עליהן. זה חשוב במיוחד אם המגלה מבקש רשות לבדוק. ודאו שכל התשובות ברורות וישירות.
השיבו למגלה באמצעות איש קשר מורשה לענייני אבטחה ו/או תהליך אבטחה מורשה.
טוב: תשובה מכתובת דוא"ל ייעודית לאבטחה, כגון "security@example.com".
לדוגמה אלה רעים: תשובה מכתובת דוא"ל לשימוש כללי, כגון "help@example.com", או מכל מי שאינו איש מקצוע מורשה לאבטחה.
הודיעו למגלה שהבעיה מוכרת כדיווח אבטחה.
טוב: ניסוח ייעודי לאבטחה, כגון "צוות האבטחה שלנו קיבל את דיווח החשיפה האחראית שלך", או "לתהליך האבטחה שלנו יש את השלבים הבאים", או "המידע שלך נמצא כעת במעקב האבטחה שלנו עם מספר מזהה XYZ" וכדומה.
רע: ניסוח כללי, כגון "אנחנו מעריכים את העסקים שלך", או "אנחנו לוקחים אבטחה ברצינות", ניסוח של העברת האחריות כגון "העברנו את הדוא"ל שלך למחלקה אחרת" וכדומה.
שלב 3: פעלו בתום לב
שלב 3 מיועד למגלה וליצרן יחד: פעלו בתום לב.
הבינו שחשיפה מתואמת של פגיעויות מתארת תהליך המבוסס על תום לב.
מטרה מס' 1 היא תום לב בסיוע למשתמשים להגן על עצמם מפני סיכוני אבטחה.
מטרה מס' 2 היא תום לב בטיפול בבעיית האבטחה.
המגלה ו/או היצרן רשאים לבחור בתום לב לערב אנשי אבטחה נוספים, למשל על ידי פנייה לחוקרי אבטחה רלוונטיים אחרים כדי לסייע בבעיה.
הבינו שחשיפה מתואמת של פגיעויות אינה יוצרת כל מחויבות.
המגלה ו/או היצרן רשאים לפרוש בכל עת, מכל סיבה, עם אזהרה או בלעדיה. מנומס לשמור על כל הרלוונטיים מעודכנים ומיודעים, אך זה לא תמיד אפשרי, מעשי או רצוי.
חשיפה מתואמת של פגיעויות אינה יוצרת כל הסכם משפטי. אם למגלה וליצרן כבר יש הסכם משפטי, אנו מציעים שכל המעורבים יתייעצו עם עורכי הדין המתאימים; אל תשתמשו במסמך זה כייעוץ משפטי.
הבינו שחשיפה מתואמת של פגיעויות שואפת להשתמש בתקשורת טובה ושואפת לדחות איומים.
חשיפה מתואמת של פגיעויות היא הטובה ביותר כאשר כל המעורבים מבינים שמטרה מס' 1 היא לסייע למשתמשים להגן על עצמם מפני סיכוני אבטחה, ומטרה מס' 2 היא לטפל בבעיית האבטחה.
חשיפה מתואמת של פגיעויות דוחה כל סוג של איום בנקמה, הפחדה, השעיה, ביטול, סחיטה, נטל מעקב או האשמת הקורבן.
הבינו שחשיפה מתואמת של פגיעויות עשויה להיות בעלת משמעויות שונות לאנשים שונים.
למגלה וליצרן עשויה להיות הבנה שונה של חשיפה מתואמת של פגיעויות. ההבנות הללו אינן בהכרח מתיישבות זו עם זו. תום לב כולל את הבנת כל המעורבים בכך.
יצרנים מסוימים מפרסמים מדיניות חשיפה מתואמת של פגיעויות. אלה יכולות להיות הנחיה מועילה. אם מגלה בוחר להשתמש בסוג אחר של חשיפה מתואמת של פגיעויות, או שיש לו הבנה שונה של חשיפה אחראית, זה בהחלט בסדר.
הבינו שבדרך כלל המגלה עושה טובה למפרסם.
בדרך כלל המגלה אינו זקוק לרשותו של איש כדי לפרסם פגיעויות.
בדרך כלל המידע של המגלה מסייע למפרסם.
אמתו הצלחה
לאחר שהבעיה נפתרה, על היצרן לאמת הצלחה.
האם כל האנשים והתהליכים טיפלו בחשיפה בהצלחה? אם כן, טוב. אם לא, שקלו לבצע מחקר לאחר פעולה, כגון ניתוח שורש הבעיה (RCA), דוחות לאחר מעשה (post-mortem), דיאגרמות אישיקאווה או ניתוח סיבתי המבוסס על תורת המערכות (CAST).
האם בעיות פתוחות כלשהן מוינו (triage) ונמצאות במעקב?
האם היצרן והמגלה שניהם מבינים מה לעשות בכל צעדים הבאים? זה חשוב במיוחד לעשות נכון למקרה שיהיו חשיפות מתואמות נוספות של פגיעויות.
הנחיות
הנחיות לחשיפה מתואמת של פגיעויות יכולות לבוא מתחומים רבים, כגון מומחי אתיקה, תומכים משפטיים, הציפיות הסבירות של הציבור הרחב וכדומה.
אם אתם מחפשים הנחיות, ייתכן שיעניינו אתכם שלושת התחומים הללו, המתוארים כולם להלן.
השומרוני הטוב
חובת הצלה
חובת זהירות
השומרוני הטוב
חוקי השומרוני הטוב מעניקים הגנה משפטית לאנשים המושיטים סיוע סביר למי שנפצעו, חולים, בסכנה או חסרי יכולת, או למי שהם מאמינים שהם כאלה. ההגנה נועדה להפחית את היסוס העומדים מנגד לעזור, מחשש שיתבעו או יועמדו לדין.
חובת הצלה
חובת הצלה היא מושג המתאר נסיבות שבהן ניתן להטיל אחריות על צד בשל כך שלא בא להצלת צד אחר הנמצא בסכנה. לחובת הצלה עשויים להיות היבטים מוסריים ו/או משפטיים.
חובת זהירות
חובת זהירות היא התחייבות לעמוד בסטנדרט של זהירות סבירה בעת ביצוע כל מעשה שעלול באופן צפוי להזיק לאחרים. לחובת זהירות עשויים להיות היבטים מוסריים ו/או משפטיים. כמה היבטים שיש לשקול הם: הצפיות של הנזק או הפגיעה, הגודל האפשרי של הנזק או הפגיעה הפוטנציאליים, החשיבות או הערך החברתי של הפעילות שבה עוסק הנתבע, התועלת של ההתנהלות לנתבע, היתכנות ההתנהלות החלופית, העלויות והנטלים הכרוכים בהתנהלות החלופית, התועלת היחסית של ההתנהלות החלופית והבטיחות היחסית של ההתנהלות החלופית.
מקרים מיוחדים
צוותי האבטחה שלנו ראו מגוון רחב של מקרים מיוחדים.
אנו מתארים אותם כאן כדי לסייע לאנשים להבין היכן יש מגוון רחב של דעות לגבי מה שעשוי להיות בסדר ומה שעשוי שלא להיות בסדר. אנו ממליצים שכל המעורבים יתקשרו בתום לב בנושאים אלה.
גישה למידע של משתמשים אחרים
דוגמה: אתם מגלים שכתובת URL מכילה את מזהה המשתמש שלכם, וחושפת באג, ואתם מאמינים שאפשר לערוך את ה-URL כדי לשנות את מזהה המשתמש שלכם למזהה משתמש אחר.
האם בסדר שהמגלה יעשה זאת, למשל במטרה היחידה לגלות אם זה משפיע גם על משתמשים אחרים?
האם חשוב יותר להבין במהירות את היקף הסיכון לכל המשתמשים מאשר להגן על כמה משתמשים שהמידע שלהם אולי כבר גלוי להאקרים?
האם בסדר שהמגלה יעשה זאת עם כמה משתמשים שרוצים?
האם בסדר שהמגלה ינסה ליצור קשר עם משתמשים כדי להודיע להם שהם מושפעים? האם בסדר להציע הצעות להפחתת הנזק?
מניעת שירות
דוגמה: אתם מגלים באג שמשעה בטעות את החשבון שלכם, למשל על ידי הפעלת נעילת סיסמה.
- האם זה נחשב להתקפת מניעת שירות?
דוא"ל לא רצוי
דוגמה: אתם מנסים לדווח על בעיית אבטחה לאנשים בחברה שאתם חושבים שהם רלוונטיים, ושאותם אתם מגלים על ידי מחקר ב-LinkedIn, Facebook וכדומה, או על ידי שימוש במוסכמות שמות כגון "webmaster@example.com" או "security@example.com".
האם זה בסדר?
האם זה נחשב לדוא"ל לא רצוי?
האם זה נחשב לדוא"ל לא מורשה?
קבוצות מוחרגות
דוגמה: אתם בקבוצה מוחרגת, כגון קטין, או ברשימת סנקציות, או במדינה ברשימת סנקציות.
האם בסדר שתגישו דיווח?
האם בסדר לדווח באופן אנונימי?
האם בסדר לשנות בכוונה מידע שעשוי לזהות, למשל כדי להימלט מהקבוצה המוחרגת, ובמטרה לעזור לחשיפה להגיע לאנשים הנכונים?
צד שלישי
דוגמה: אתם מגלים שלתוכנה של חברה יש באג הקשור לצד שלישי, כגון שילוב עם תוכנה אחרת או אתר אחר.
האם בסדר שתדווחו על כל המידע שאתם מוצאים לשני הצדדים?
האם נחוץ לעשות שתי חשיפות אחראיות שונות, למשל דיווח אחד לחברה אחת ודיווח שונה לחברת הצד השלישי, במטרה להגביל את המידע הנשלח לכל חברה?
האם בסדר שהמגלה יקשר בין החברות?
תוכנה מפריעה
דוגמה: אתם מיומנים מספיק כדי לכתוב וירוס שאתם מאמינים שסביר שיסייע למשתמשים להגן על עצמם מפני סיכון האבטחה, או לזהות אם הם בסיכון, או לתקן את סיכון האבטחה.
האם זה בסדר?
האם בסדר שהמגלה יפנה משתמשים לתוכנה כזו ו/או למדריכים או הדרכות המתארים כיצד ליצור סוג זה של תוכנה?
חשיפה מתואמת של פגיעויות לעומת חשיפה אחראית
חשיפה מתואמת של פגיעויות היא המונח המועדף.
- ההיבט החשוב ביותר הוא התיאום בין המגלה ליצרן.
חשיפה אחראית (responsible disclosure) היא מונח שיצא משימוש.
- לאנשים יש השקפות שונות לגבי משמעות האחריות. לדוגמה, יש אנשים הטוענים שאחראי שהמגלה יודיע לציבור מיד ללא קשר לכל אינטראקציה עם היצרן, ושלא אחראי לעשות חשיפה מתואמת של פגיעויות כי היא מסתירה מידע מהציבור.
מעקב
- חבילה: coordinated-disclosure
- אתר: https://github.com/coordinated-vulnerability-disclosure/coordinated-vulnerability-disclosure
- שכפול: https://github.com/coordinated-vulnerability-disclosure/coordinated-vulnerability-disclosure
- גרסה: 2.7.0
- נוצר: 2017-09-21
- עודכן: 2026-06-08T06:53:18Z
- רישיון: GPL או GFDL או צרו קשר לקבלת רישיון מותאם
- איש קשר: Joel Parker Henderson (http://joelparkerhenderson.com)
- מעקב: f44c30d1b876f8987cf78c727e573542