प्रॉम्प्ट और दायरा
यह सामान्य साक्षात्कार प्रश्न यह परीक्षण करता है कि क्या आप एक छोटी सार्वजनिक फ़ाइल को संपूर्ण सुरक्षा-संचालन वर्कफ़्लो (security-operations workflow) में शामिल कर सकते हैं। इसका उद्देश्य केवल फ़ील्ड्स को याद करके सुनाना नहीं है; बल्कि रिपोर्टिंग एंट्री पॉइंट, प्राधिकरण सीमा (authorization boundary), रिस्पॉन्स ओनरशिप और पॉलिसी से जुड़े वादों को आपस में जोड़ना है।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
- क्या आप RFC 9116 के
/.well-known/security.txtस्थान और आवश्यक फ़ील्ड्स को जानते हैं। - क्या आप खोज (discovery), सत्यापन (validation), समन्वित प्रकटीकरण (coordinated disclosure) और आपातकालीन प्रतिक्रिया (emergency response) के बीच अंतर कर सकते हैं।
- क्या आप एक लावारिस (unattended) मेलबॉक्स, प्राइवेट की (private key), या बिना ओनरशिप वाले रिस्पॉन्स-टाइम के वादे को प्रकाशित करने से बचते हैं।
- क्या आप ऑन-कॉल ओनरशिप, टिकटिंग, डिडुप्लीकेशन और स्थिति अपडेट डिज़ाइन कर सकते हैं जो एंट्री पॉइंट को कार्यशील बनाते हैं।
पूछने के लिए स्पष्टीकरण संबंधी प्रश्न
पहले पुष्टि करें कि कौन से डोमेन और उत्पाद दायरे में हैं, क्या कई टीमें संपत्तियों (assets) की मालिक हैं, क्या थर्ड-पार्टी होस्टेड संपत्तियां स्वीकार की जाती हैं, प्रत्येक चैनल के लिए ऑन-कॉल पर कौन है, कौन से परीक्षण अधिकृत हैं, और क्या वल्नरेबिलिटी-डिस्क्लोज़र नीति पहले से मौजूद है। यह भी स्पष्ट करें कि क्या लक्ष्य केवल खोजने योग्यता (discoverability) है या इसमें पुरस्कार, एन्क्रिप्टेड सबमिशन और समन्वित-प्रकटीकरण तिथियां भी शामिल हैं।
30-सेकंड उत्तर ढांचा
मैं प्रत्येक सार्वजनिक संपत्ति के लिए HTTPS पर /.well-known/security.txt पर एक UTF-8 प्लेन-टेक्स्ट फ़ाइल प्रकाशित करूंगा। मैं एक वैध Contact और एक भविष्य की Expires बनाए रखूंगा, फिर Policy, Canonical, Encryption, या Acknowledgments केवल तभी जोड़ूंगा जब वे प्रक्रियाएं वास्तव में मौजूद हों। यह फ़ाइल केवल एक शोधकर्ता को एंट्री पॉइंट खोजने में मदद करती है; बैकएंड को अभी भी प्राधिकरण दायरा, ऑन-कॉल ओनरशिप, टिकट, डिडुप्लीकेशन, गंभीरता मूल्यांकन और सुरक्षित स्थिति संचार की आवश्यकता होती है। लॉन्च से पहले मैं HTTPS, समाप्ति (expiry), लिंक अनुमतियां और जिम्मेदार रोटेशन को सत्यापित करूंगा।
चरण-दर-चरण समाधान
1. संपत्तियों और एंट्री-पॉइंट सीमा को परिभाषित करें
केवल एक मार्केटिंग होमपेज पर फ़ाइल रखने के बजाय प्राथमिक डोमेन, उत्पाद डोमेन और उच्च-जोखिम वाले API को सूचीबद्ध करें जिन्हें कवरेज की आवश्यकता है। Contact को ऐसे मेलबॉक्स या HTTPS फ़ॉर्म पर इंगित करना चाहिए जो वास्तव में रिपोर्टों को संसाधित कर सके; एक लावारिस व्यक्तिगत मेलबॉक्स एकमात्र मार्ग नहीं होना चाहिए। यदि विभिन्न टीमें संपत्तियों की मालिक हैं, तो दस्तावेज़ करें कि रिपोर्ट को कैसे रूट किया जाता है।
2. RFC 9116 फ़ील्ड्स को भरें और लगातार सत्यापित करें
Contact और Expires आवश्यक हैं; Expires को भविष्य का समाप्ति समय व्यक्त करना चाहिए। Policy अधिकृत परीक्षण और प्रकटीकरण नियमों से लिंक हो सकता है, Canonical कैनोनिकल फ़ाइल की पहचान कर सकता है, Encryption केवल तभी उपयुक्त होता है जब एक रखरखाव की गई पब्लिक की मौजूद हो, और Acknowledgments या Hiring वैकल्पिक हैं। HTML रेंडरिंग पर निर्भर किए बिना, फ़ाइल को HTTPS /.well-known/security.txt पर text/plain के रूप में प्रस्तुत करें।
3. फ़ाइल को रिस्पॉन्स वर्कफ़्लो से कनेक्ट करें
जब कोई रिपोर्ट आती है, तो एक अप्रत्याशित टिकट पहचानकर्ता बनाएं और प्राप्ति का समय, संपत्ति, पुनरुत्पादन के चरण और शोधकर्ता की संचार प्राथमिकता दर्ज करें। ऑन-कॉल व्यक्ति पहले प्राधिकरण दायरे की जांच करता है, फिर डिडुप्लीकेशन करता है, प्रभाव का आकलन करता है और एक ओनर नियुक्त करता है। उच्च-जोखिम वाली रिपोर्टें आपातकालीन पथ में जाती हैं; सामान्य रिपोर्टें नियमित कतार का उपयोग करती हैं, और दोनों के लिए एक ऑडिट ट्रेल होता है।
4. SLA का आविष्कार करने के बजाय एक डिस्क्लोज़र नीति लिखें
नीति में अनुमत अनुसंधान, निषिद्ध व्यवहार, संवेदनशील सामग्री का सुरक्षित हस्तांतरण, पुरस्कार (यदि कोई हो), सार्वजनिक प्रकटीकरण की अनुमति कब है, और सद्भावपूर्ण परीक्षण (good-faith testing) को कैसे संभाला जाता है, यह समझाया जाना चाहिए। केवल व्यावहारिक पावती समय (acknowledgment times) और अपडेट लय को लिखित रूप में रखें। किसी RFC फ़ील्ड को इस वादे के रूप में न समझें कि प्रत्येक रिपोर्ट को घंटों की एक निश्चित संख्या के भीतर ठीक कर दिया जाएगा।
5. एंट्री पॉइंट और रिपोर्ट डेटा को सुरक्षित रखें
सार्वजनिक फ़ाइल में प्राइवेट की, आंतरिक होस्टनाम, व्यक्तिगत फ़ोन नंबर या अप्रकाशित घटना विवरण नहीं होने चाहिए। अटैचमेंट के प्रकार और आकार को सीमित करें, मेल और टिकट सिस्टम तक पहुंच को प्रतिबंधित करें, और रॉ रिपोर्ट में स्क्रिप्ट और लिंक को अविश्वसनीय इनपुट के रूप में मानें। सुरक्षा टीम समृद्ध आंतरिक संदर्भ रख सकती है, जबकि रिपोर्टर को दिए जाने वाले उत्तरों में केवल स्वीकृत तथ्यों का ही खुलासा किया जाता है।
6. ऑब्जर्वेबिलिटी के साथ साबित करें कि एंट्री पॉइंट काम करता है
फ़ाइल की 200 प्रतिक्रिया, HTTPS प्रमाणपत्र, Expires का शेष समय, ऑन-कॉल रोटेशन और फ़ॉर्म-से-टिकट रूपांतरण की निगरानी करें। अलर्ट, डिडुप्लीकेशन और एस्केलेशन को सत्यापित करने के लिए हानिरहित परीक्षण रिपोर्टों का उपयोग करें; अभ्यास के लिए कभी भी वास्तविक वल्नरेबिलिटी का उपयोग न करें। जांचें कि CDN, रीडायरेक्ट और मल्टी-रीजन परिनियोजन पुरानी या समाप्त हो चुकी प्रतिलिपि प्रस्तुत न करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पहले उन सार्वजनिक डोमेन को सूचीबद्ध करूंगा जिन्हें कवरेज की आवश्यकता है और प्रत्येक के लिए HTTPS /.well-known/security.txt पर एक UTF-8 प्लेन-टेक्स्ट फ़ाइल प्रकाशित करूंगा। Contact एक स्टाफ वाले मेलबॉक्स या फ़ॉर्म को इंगित करेगा, जबकि Expires भविष्य में सेट किया जाएगा और समाप्ति अलर्ट द्वारा कवर किया जाएगा। मैं Policy, Canonical, या Encryption केवल तभी जोड़ूंगा जब वे प्रक्रियाएं और कुंजियां बनाए रखी जा रही हों। फ़ाइल मरम्मत की समय सीमा का वादा नहीं करेगी; नीति अधिकृत दायरे, निषिद्ध व्यवहार, संवेदनशील-सामग्री हस्तांतरण, पुरस्कार और समन्वित प्रकटीकरण का उल्लेख करेगी। रिपोर्टें दायरा जांच, डिडुप्लीकेशन, गंभीरता मूल्यांकन और ओनरशिप के लिए एक प्रतिबंधित टिकट प्रणाली में प्रवेश करेंगी, जिसमें उच्च-जोखिम वाले मामलों के लिए एक आपातकालीन पथ होगा। मैं लॉन्च से पहले HTTPS, कैशिंग, अनुमतियों, ऑन-कॉल कवरेज और नवीनीकरण को सत्यापित करूंगा, फिर पहुंच योग्यता, टिकट रूपांतरण और प्रतिक्रिया स्थितियों की निगरानी करूंगा। फ़ाइल चैनल को खोजने योग्य बनाती है; वर्कफ़्लो और ओनरशिप सुरक्षा क्षमता प्रदान करते हैं।
सामान्य गलतियां
- ऑन-कॉल ओनर, टिकट कतार या एस्केलेशन पथ के बिना फ़ाइल बनाना।
Expiresको छोड़ देना, जिससे शोधकर्ताओं के पास ऐसी संपर्क जानकारी रह जाती है जो अब काम नहीं कर सकती है।- एक प्राइवेट की, आंतरिक पता या व्यक्तिगत फ़ोन नंबर प्रकाशित करना।
- मरम्मत SLA, इनाम राशि या प्रकटीकरण तिथि का ऐसा वादा करना जिसे टीम पूरा नहीं कर सकती।
- एक स्थिर HTTPS एंट्री पॉइंट को HTTP, लॉगिन रीडायरेक्ट या पुरानी CDN प्रतिलिपि से बदलना।
- प्राधिकरण और प्रभाव की जांच होने से पहले पुनरुत्पादन विवरण प्रकाशित करना।
अनुवर्ती प्रश्न और उत्तर
क्या security.txt वल्नरेबिलिटी-डिस्क्लोज़र नीति का स्थान ले सकता है?
नहीं। यह शोधकर्ताओं को Contact और Policy लिंक खोजने में मदद करता है; प्राधिकरण दायरा, सद्भावपूर्ण परीक्षण, पुरस्कार, प्रकटीकरण समन्वय और आपातकालीन नियम अभी भी नीति का हिस्सा हैं।
Expires की आवश्यकता क्यों है?
संपर्क और प्रक्रियाएं बदलते हैं। Expires स्वचालित जांचों को उस फ़ाइल की पहचान करने की अनुमति देता है जो पुरानी हो सकती है ताकि टीम इसे अनिश्चित काल के लिए वैध दिखने वाले पुराने मेलबॉक्स को छोड़ने के बजाय अपडेट करे।
यदि किसी समूह के पास कई उत्पाद डोमेन हैं तो क्या होगा?
प्रत्येक स्वतंत्र स्वामित्व वाले डोमेन के लिए संबंधित फ़ाइल प्रकाशित करें और प्रामाणिक स्रोत को समझाने के लिए Canonical या नीति लिंक का उपयोग करें। प्रत्येक एंट्री पॉइंट को अभी भी उस टीम तक पहुंचना होगा जो रिपोर्टों को रूट कर सकती है; किसी लावारिस पते की प्रतिलिपि बनाना पर्याप्त नहीं है।
किसी शोधकर्ता द्वारा संदिग्ध ज़ीरो-डे की रिपोर्ट करने के बाद पहला कदम क्या है?
रिपोर्ट तक पहुंच को प्रतिबंधित करें, स्रोत और संपत्ति के दायरे की पुष्टि करें, समय और साक्ष्य रिकॉर्ड करें, और आपातकालीन प्रभाव मूल्यांकन के लिए सुरक्षा ओनर को सूचित करें। असत्यापित विवरणों को सार्वजनिक चैनल पर अग्रेषित न करें या शोधकर्ता से केवल रिपोर्ट को अधिक पूर्ण बनाने के लिए परीक्षण का विस्तार करने के लिए न कहें।