Coordinated vulnerability disclosure

समन्वित भेद्यता प्रकटीकरण (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. रिपॉज़िटरी फ़ोल्डर में समन्वित भेद्यता प्रकटीकरण नीतियों के उदाहरण शामिल करना।

हम पुल रिक्वेस्ट, GitHub इश्यू, या security@joelparkerhenderson.com पर ईमेल का स्वागत करते हैं।

समन्वित भेद्यता प्रकटीकरण क्या है?

जब कोई व्यक्ति कोई सुरक्षा समस्या (जैसे सॉफ़्टवेयर बग) खोजता है और उसकी रिपोर्ट निर्माता (जैसे वह कंपनी जो सॉफ़्टवेयर बनाती है) को करना चाहता है, तो समन्वित भेद्यता प्रकटीकरण तीन चरणों का वर्णन करता है।

चरण:

  1. खोजकर्ता सद्भावना से निर्माता को समस्या की निजी तौर पर रिपोर्ट करता है।

  2. निर्माता सद्भावना से उपयोगकर्ताओं की रक्षा करने और समस्या का समाधान करने का प्रयास करता है।

  3. एक निश्चित समय के बाद, सुरक्षा समस्या सार्वजनिक कर दी जाती है।

चरण 1: समस्या की रिपोर्ट करें

चरण 1 खोजकर्ता के लिए है: सद्भावना से निजी तौर पर समस्या की रिपोर्ट करें।

  • अच्छा: खोजकर्ता प्रासंगिक जानकारी निर्माता को भेजता है, जैसे निर्माता के सुरक्षा ईमेल पते (आमतौर पर "security@example.com") पर ईमेल द्वारा, या निर्माता की वेबसाइट पर वेब फ़ॉर्म के ज़रिए (आमतौर पर "https://www.example.com/security")।

  • बुरा: रिपोर्ट को सार्वजनिक ब्लॉग पर पोस्ट करना, मीडिया को सूचित करना, धमकियाँ देना, या सुरक्षा समस्या को हैकरों को बेचने की कोशिश करना आदि।

  • सुझाव: खोजकर्ता गुमनाम रहना चुन सकता है; निर्माता भी गुमनाम रहना चुन सकता है।

यदि आप चाहें, तो समस्या के प्रति जागरूक बने रहें।

  • अच्छा: संवाद के रास्ते खुले रखना, अनुवर्ती जानकारी देना, या स्थिति पर नज़र रखना।

  • बुरा: समस्या को भूल जाना।

  • सुझाव: खोजकर्ता मदद करना या न करना चुन सकता है, संपर्क में रहना या न रहना भी चुन सकता है, और परिस्थितियाँ बदलने पर व्यवस्था बदलना भी चुन सकता है।

यदि आप चाहें, तो समस्या को दूसरों के सामने प्रकट करें।

  • अच्छा: निर्दिष्ट समय तक प्रतीक्षा करके फिर सार्वजनिक करना, जैसे प्रासंगिक जानकारी को किसी सुरक्षा समाचार साइट पर पोस्ट करना, प्रासंगिक तृतीय-पक्ष सुरक्षा शोधकर्ताओं से संपर्क करना, या किसी सार्वजनिक सोशल साइट पर समस्या की घोषणा करना आदि।

  • बुरा: समस्या को दूसरों के सामने प्रकट न करना, जब तक कि आपको न लगे कि इससे आपके या दूसरों के लिए तुलनात्मक मात्रा से अधिक जोखिम पैदा होगा।

  • सुझाव: यदि परिस्थितियाँ बदलती हैं, जैसे अधिक जोखिम या वास्तविक दुनिया में सक्रिय एक्सप्लॉइट का पता चलता है, तो खोजकर्ता समस्या को दूसरों के सामने जल्दी प्रकट कर सकता है।

चरण 2: संपर्क सुनिश्चित करें

चरण 2 निर्माता के लिए है: सुनिश्चित करें कि संपर्क व्यवहार्य हैं।

  • अच्छा: निर्माता सुरक्षा संपर्क ईमेल पता (परंपरा से "security@example.com") प्रकाशित करता है और आदर्श रूप से सुरक्षित ईमेल एन्क्रिप्शन कुंजी भी।

  • अच्छा: निर्माता सुरक्षा संपर्क वेब पेज (परंपरा से "https://www.example.com/security") प्रकाशित करता है और आदर्श रूप से पेज को आसानी से खोजने योग्य बनाता है, जैसे वेबसाइट के फ़ुटर, साइटमैप और खोज के ज़रिए।

  • बुरा: निर्माता ईमेल पता या वेब पेज नहीं देता, या उन्हें आसानी से खोजने योग्य नहीं बनाता।

कर्मचारियों की क्षमताएँ सुनिश्चित करें।

  • अच्छा: निर्माता सहायता कर्मचारियों को प्रशिक्षित करता है कि सुरक्षा संबंधी पूछताछ मिलने पर क्या करना है, जैसे संपर्क जानकारी के साथ कैसे जवाब देना है, या पूछताछ को सही आंतरिक टीम को कैसे अग्रेषित करना है।

  • अच्छा: निर्माता समय-समय पर सत्यापित करता है कि कर्मचारियों की क्षमताएँ काम कर रही हैं।

  • बुरा: निर्माता प्रशिक्षित नहीं करता या सत्यापित नहीं करता।

समय-सीमा के भीतर खोजकर्ता को जवाब दें।

  • यदि खोजकर्ता समय-सीमा निर्दिष्ट नहीं करता, तो एक कार्य दिवस का उपयोग करें, क्योंकि यह उद्योग मानक है और वर्तमान उद्योग की सर्वोत्तम प्रथा है।

  • यदि खोजकर्ता प्रश्न पूछता है, तो उनके उत्तर दें। यह विशेष रूप से महत्वपूर्ण है यदि खोजकर्ता परीक्षण की अनुमति माँगता है। सुनिश्चित करें कि सभी उत्तर स्पष्ट और सीधे हों।

अधिकृत सुरक्षा संपर्क और/या अधिकृत सुरक्षा प्रक्रिया के माध्यम से खोजकर्ता को जवाब दें।

  • अच्छा: सुरक्षा-विशिष्ट ईमेल पते से जवाब, जैसे "security@example.com"।

  • उदाहरण के लिए ये बुरे हैं: सामान्य-उद्देश्य ईमेल पते से जवाब, जैसे "help@example.com", या किसी ऐसे व्यक्ति से जो अधिकृत सुरक्षा पेशेवर नहीं है।

खोजकर्ता को जवाब दें कि समस्या को सुरक्षा रिपोर्ट के रूप में मान्यता दी गई है।

  • अच्छा: सुरक्षा-विशिष्ट शब्दावली, जैसे "हमारी सुरक्षा टीम को आपकी ज़िम्मेदार प्रकटीकरण रिपोर्ट मिल गई है", या "हमारी सुरक्षा प्रक्रिया के अगले चरण ये हैं", या "आपकी जानकारी अब हमारे सुरक्षा ट्रैकर में आईडी संख्या XYZ के साथ है" आदि।

  • बुरा: सामान्य-उद्देश्य शब्दावली, जैसे "हम आपके व्यवसाय की सराहना करते हैं", या "हम सुरक्षा को गंभीरता से लेते हैं", ज़िम्मेदारी टालने वाली शब्दावली जैसे "हमने आपका ईमेल दूसरे विभाग को भेज दिया है" आदि।

चरण 3: सद्भावना से काम करें

चरण 3 खोजकर्ता और निर्माता दोनों के लिए है: सद्भावना से मिलकर काम करें।

समझें कि समन्वित भेद्यता प्रकटीकरण एक सद्भावनापूर्ण प्रक्रिया का वर्णन करता है।

  • लक्ष्य #1 है उपयोगकर्ताओं को सुरक्षा जोखिमों से खुद को बचाने में मदद करने की सद्भावना।

  • लक्ष्य #2 है सुरक्षा समस्या का समाधान करने की सद्भावना।

  • खोजकर्ता और/या निर्माता सद्भावना से अन्य सुरक्षा लोगों को शामिल करना चुन सकते हैं, जैसे समस्या में मदद के लिए अन्य प्रासंगिक सुरक्षा शोधकर्ताओं से संपर्क करना।

समझें कि समन्वित भेद्यता प्रकटीकरण कोई दायित्व पैदा नहीं करता।

  • खोजकर्ता और/या निर्माता किसी भी समय, किसी भी कारण से, चेतावनी के साथ या बिना, पीछे हट सकते हैं। सभी संबंधित लोगों को सूचित और अद्यतन रखना शिष्टाचार है, पर यह हमेशा संभव, व्यावहारिक या वांछनीय नहीं होता।

  • समन्वित भेद्यता प्रकटीकरण कोई कानूनी समझौता नहीं बनाता। यदि खोजकर्ता और निर्माता के बीच पहले से कानूनी समझौता है, तो हम सुझाव देते हैं कि सभी संबंधित लोग उपयुक्त वकीलों से परामर्श करें; इस दस्तावेज़ को कानूनी सलाह के रूप में उपयोग न करें।

समझें कि समन्वित भेद्यता प्रकटीकरण का उद्देश्य अच्छे संवाद का उपयोग करना और धमकियों को अस्वीकार करना है।

  • समन्वित भेद्यता प्रकटीकरण तब सबसे अच्छा होता है जब सभी संबंधित लोग समझते हैं कि लक्ष्य #1 उपयोगकर्ताओं को सुरक्षा जोखिमों से खुद को बचाने में मदद करना है, और लक्ष्य #2 सुरक्षा समस्या का समाधान करना है।

  • समन्वित भेद्यता प्रकटीकरण प्रतिशोध, धमकी, निलंबन, निरस्तीकरण, जबरन वसूली, अनुवर्ती कार्रवाई के बोझ, या पीड़ित को दोष देने की किसी भी तरह की धमकी को अस्वीकार करता है।

समझें कि समन्वित भेद्यता प्रकटीकरण का अलग-अलग लोगों के लिए अलग-अलग मतलब हो सकता है।

  • खोजकर्ता और निर्माता की समन्वित भेद्यता प्रकटीकरण की समझ अलग हो सकती है। ये समझ एक-दूसरे से मेल नहीं खा सकतीं। सद्भावना में यह शामिल है कि सभी संबंधित लोग इसे समझें।

  • कुछ निर्माता समन्वित भेद्यता प्रकटीकरण नीतियाँ प्रकाशित करते हैं। ये उपयोगी मार्गदर्शन हो सकती हैं। यदि कोई खोजकर्ता किसी अलग तरह का समन्वित भेद्यता प्रकटीकरण चुनता है, या ज़िम्मेदार प्रकटीकरण की उसकी समझ अलग है, तो यह बिल्कुल ठीक है।

समझें कि आमतौर पर खोजकर्ता प्रकाशक पर एक एहसान कर रहा होता है।

  • आमतौर पर खोजकर्ता को भेद्यताएँ प्रकाशित करने के लिए किसी की अनुमति की आवश्यकता नहीं होती।

  • आमतौर पर खोजकर्ता की जानकारी प्रकाशक की मदद करती है।

सफलता की पुष्टि करें

समस्या हल होने के बाद, निर्माता को सफलता की पुष्टि करनी चाहिए।

  • क्या सभी लोगों और प्रक्रियाओं ने प्रकटीकरण को सफलतापूर्वक संभाला? यदि हाँ, तो अच्छा। यदि नहीं, तो घटना-पश्चात शोध पर विचार करें, जैसे मूल कारण विश्लेषण (RCA), पोस्ट-मॉर्टम रिपोर्ट, इशिकावा आरेख, या सिस्टम सिद्धांत पर आधारित कारणात्मक विश्लेषण (CAST)।

  • क्या शेष बचे मुद्दों का वर्गीकरण और ट्रैकिंग हो रही है?

  • क्या निर्माता और खोजकर्ता दोनों समझते हैं कि आगे के किसी भी कदम के लिए क्या करना है? यह विशेष रूप से इसलिए सही करना ज़रूरी है कि आगे और समन्वित भेद्यता प्रकटीकरण हो सकते हैं।

मार्गदर्शन

समन्वित भेद्यता प्रकटीकरण के लिए मार्गदर्शन कई क्षेत्रों से आ सकता है, जैसे नैतिकता विशेषज्ञ, कानूनी पैरोकार, आम जनता की उचित अपेक्षाएँ आदि।

यदि आप मार्गदर्शन खोज रहे हैं, तो आपको ये तीन क्षेत्र रुचिकर लग सकते हैं, जिनका वर्णन नीचे किया गया है।

  • अच्छा सामरी

  • बचाव का कर्तव्य

  • सावधानी का कर्तव्य

अच्छा सामरी

विकिपीडिया: गुड सेमेरिटन कानून

गुड सेमेरिटन कानून उन लोगों को कानूनी संरक्षण देते हैं जो घायल, बीमार, संकट में, या अन्यथा अक्षम लोगों (या जिन्हें वे ऐसा मानते हैं) को उचित सहायता देते हैं। इस संरक्षण का उद्देश्य मुकदमे या अभियोजन के डर से सहायता करने में दर्शकों की हिचकिचाहट को कम करना है।

बचाव का कर्तव्य

विकिपीडिया: बचाव का कर्तव्य

बचाव का कर्तव्य एक अवधारणा है जो ऐसी परिस्थिति का वर्णन करती है जिसमें किसी पक्ष को संकट में पड़े दूसरे पक्ष के बचाव में न आने के लिए उत्तरदायी ठहराया जा सकता है। बचाव के कर्तव्य के नैतिक और/या कानूनी क्षेत्र हो सकते हैं।

सावधानी का कर्तव्य

विकिपीडिया: सावधानी का कर्तव्य

सावधानी का कर्तव्य किसी भी ऐसे कार्य को करते समय उचित सावधानी के मानक के प्रति दायित्व है जिससे दूसरों को पूर्वानुमेय रूप से हानि पहुँच सकती है। सावधानी के कर्तव्य के नैतिक और/या कानूनी क्षेत्र हो सकते हैं। विचार करने योग्य कुछ पहलू हैं: हानि या चोट की पूर्वानुमेयता, संभावित हानि या चोट की संभावित गंभीरता, प्रतिवादी द्वारा किए गए कार्य का महत्व या सामाजिक मूल्य, प्रतिवादी के लिए आचरण की उपयोगिता, वैकल्पिक आचरण की व्यवहार्यता, वैकल्पिक आचरण से जुड़ी लागतें और बोझ, वैकल्पिक आचरण की सापेक्ष उपयोगिता, और वैकल्पिक आचरण की सापेक्ष सुरक्षा।

विशेष मामले

हमारी सुरक्षा टीमों ने विशेष मामलों की एक विस्तृत श्रृंखला देखी है।

हम उन्हें यहाँ इसलिए बताते हैं ताकि लोग समझ सकें कि क्या ठीक हो सकता है और क्या नहीं, इस पर कहाँ विचारों की विस्तृत श्रृंखला है। हम सुझाव देते हैं कि सभी संबंधित लोग इनके बारे में सद्भावना से संवाद करें।

अन्य उपयोगकर्ताओं की जानकारी तक पहुँच

उदाहरण: आप पाते हैं कि किसी URL में आपकी उपयोगकर्ता आईडी है, और यह एक बग उजागर करता है, और आपको लगता है कि आप URL को संपादित करके अपनी उपयोगकर्ता आईडी को किसी दूसरी उपयोगकर्ता आईडी में बदल सकते हैं।

  • क्या खोजकर्ता के लिए ऐसा करना ठीक है, जैसे केवल यह पता लगाने के उद्देश्य से कि क्या यह अन्य उपयोगकर्ताओं को भी प्रभावित कर रहा है?

  • क्या सभी उपयोगकर्ताओं के लिए जोखिम की व्यापकता को जल्दी समझना उन कुछ उपयोगकर्ताओं की रक्षा से अधिक महत्वपूर्ण है जिनकी जानकारी हैकरों को पहले से दिख रही हो सकती है?

  • क्या खोजकर्ता के लिए जितने चाहे उतने उपयोगकर्ताओं के साथ ऐसा करना ठीक है?

  • क्या खोजकर्ता के लिए उपयोगकर्ताओं से संपर्क करके उन्हें बताने की कोशिश करना ठीक है कि वे प्रभावित हैं? क्या शमन के सुझाव देना ठीक है?

सेवा-अवरोध

उदाहरण: आप एक ऐसा बग पाते हैं जो गलती से आपका खाता निलंबित कर देता है, जैसे पासवर्ड लॉक ट्रिगर करना।

  • क्या इसे सेवा-अवरोध (denial of service) हमला माना जाता है?

अनचाहा ईमेल

उदाहरण: आप कंपनी में उन लोगों को सुरक्षा समस्या की रिपोर्ट करने की कोशिश करते हैं जिन्हें आप प्रासंगिक मानते हैं, और जिन्हें आप LinkedIn, Facebook आदि पर खोजकर, या "webmaster@example.com" या "security@example.com" जैसी नामकरण परंपराओं का उपयोग करके पाते हैं।

  • क्या यह ठीक है?

  • क्या इसे अनचाहा ईमेल माना जाता है?

  • क्या इसे अनधिकृत ईमेल माना जाता है?

बहिष्कृत समूह

उदाहरण: आप किसी बहिष्कृत समूह में हैं, जैसे नाबालिग होना, या प्रतिबंध सूची में होना, या प्रतिबंध सूची वाले देश में होना।

  • क्या आपके लिए रिपोर्ट करना ठीक है?

  • क्या गुमनाम रूप से रिपोर्ट करना ठीक है?

  • क्या बहिष्कृत समूह से बचने के लिए, और प्रकटीकरण को सही लोगों तक पहुँचाने के लक्ष्य से, संभावित रूप से पहचानने योग्य जानकारी को जानबूझकर बदलना ठीक है?

तृतीय पक्ष

उदाहरण: आप पाते हैं कि किसी कंपनी के सॉफ़्टवेयर में एक बग है जिसमें कोई तृतीय पक्ष शामिल है, जैसे किसी अन्य सॉफ़्टवेयर या किसी अन्य वेबसाइट के साथ एकीकरण।

  • क्या आपके लिए अपनी पाई गई सारी जानकारी दोनों पक्षों को रिपोर्ट करना ठीक है?

  • क्या दो अलग-अलग ज़िम्मेदार प्रकटीकरण करना ज़रूरी है, जैसे एक कंपनी को एक रिपोर्ट, और तृतीय-पक्ष कंपनी को दूसरी रिपोर्ट, ताकि हर कंपनी को भेजी जाने वाली जानकारी सीमित रहे?

  • क्या खोजकर्ता के लिए कंपनियों को एक-दूसरे के संपर्क में लाना ठीक है?

विघटनकारी सॉफ़्टवेयर

उदाहरण: आप इतने कुशल हैं कि ऐसा वायरस लिख सकते हैं जिसके बारे में आपको लगता है कि वह उपयोगकर्ताओं को सुरक्षा जोखिम से खुद को बचाने, यह पहचानने कि वे जोखिम में हैं या नहीं, या सुरक्षा जोखिम को ठीक करने में मदद करेगा।

  • क्या यह ठीक है?

  • क्या खोजकर्ता के लिए उपयोगकर्ताओं को ऐसे सॉफ़्टवेयर की ओर, और/या ऐसे गाइड या ट्यूटोरियल की ओर इंगित करना ठीक है जो बताते हैं कि इस तरह का सॉफ़्टवेयर कैसे बनाया जाए?

समन्वित भेद्यता प्रकटीकरण बनाम ज़िम्मेदार प्रकटीकरण

समन्वित भेद्यता प्रकटीकरण पसंदीदा शब्द है।

  • सबसे महत्वपूर्ण पहलू खोजकर्ता और निर्माता के बीच समन्वय है।

ज़िम्मेदार प्रकटीकरण एक अप्रचलित शब्द है।

  • ज़िम्मेदार होने का मतलब लोग अलग-अलग मानते हैं। उदाहरण के लिए, कुछ लोग तर्क देते हैं कि निर्माता के साथ किसी भी बातचीत की परवाह किए बिना खोजकर्ता का जनता को तुरंत सूचित करना ज़िम्मेदारी है, और समन्वित भेद्यता प्रकटीकरण करना गैर-ज़िम्मेदाराना है क्योंकि यह जनता से जानकारी छिपाता है।

ट्रैकिंग