वीडियो की रणनीति

इस सेक्शन में हम विस्तार से चर्चा करेंगे कि अपने संगठन को, जोखिम की आशंका की जानकारी देने वाला एक सफल प्रोग्राम लॉन्च करने और चलाने के लिए कैसे तैयार करें. इसमें, आपने जो कमियां बताई हैं उन्हें ठीक करने के लिए आपको ज़रूरी सलाह भी दी जाएगी.

गड़बड़ियां ढूंढना

बाहरी सुरक्षा शोधकर्ताओं की मदद से अपने मौजूदा सुरक्षा कार्यक्रम में बढ़ोतरी करना, मुश्किल समस्याओं का पता लगाने और जोखिम की आशंका को कम करने का एक शानदार तरीका है. हालांकि, सुरक्षा से जुड़ी ऐसी बुनियादी समस्याओं का पता लगाने के लिए वीडीपी का इस्तेमाल करना, संसाधनों की बर्बादी होती है जिनका पता लगाया जा सकता है.

ऐसेट मैनेजमेंट

अगर आपको गड़बड़ियां ढूंढने की बात आती है, तो आपको बस यह पता होना चाहिए कि गड़बड़ी ढूंढने के लिए क्या करना चाहिए. आप सौ सुरक्षा टूल खरीद सकते हैं, लेकिन अगर आपकी जानकारी के बिना कोई भी टीम ऐप्लिकेशन, सिस्टम, और सेवाओं को इकट्ठा नए आवेदनों, सिस्टम, और सेवाओं को तैयार करने में मदद करने वाले लोगों और टीमों से पता करें कि क्या उन्हें इकट्ठा की जा रही चीज़ों और उन चीज़ों की इन्वेंट्री बनाने और उसे बनाए रखने की कोई प्रोसेस मौजूद है या नहीं. अगर कोई मौजूदा प्रोसेस नहीं है, तो इन टीमों के साथ मिलकर काम करने का यह शानदार मौका है. हमले की जगह की पहचान शुरू करने के लिए, अपने संगठन की एसेट को समझना सबसे अच्छा तरीका है. इस प्रोसेस के तहत, सुरक्षा टीम को सुरक्षा की समीक्षाएं देने के लिए, नए इन्फ़्रास्ट्रक्चर के डेवलपमेंट में शामिल होना चाहिए. एसेट और मालिकों की बड़ी इन्वेंट्री रखना एक अच्छी आदत है. इस तरह की इन्वेंट्री ऐसे नए पैच लागू करते समय मददगार होती है जिन्हें कुछ सिस्टम को कुछ समय के लिए बंद करने की ज़रूरत होती है. इससे उन लोगों या टीमों का रोड मैप बनाया जाता है जिन्हें जानकारी देने की ज़रूरत होती है. साथ ही, यह भी बताया जाता है कि इन टीमों या सिस्टम पर इसका असर क्यों पड़ा है. एसेट मैनेजमेंट की एक मज़बूत प्रोसेस होने से, यह पक्का होता है कि मालिकों को प्रक्रिया में पहले ही पहचान लिया जाए और उन्हें नियमित रूप से अपडेट किया जाए. साथ ही, संगठन के सभी सिस्टम सही तरीके से काम करें.

अपने-आप एसेट मैनेजमेंट के अलावा, इस बात पर भी ध्यान दें कि अपने संगठन से जुड़ी एसेट की पहचान करने के लिए, कौनसे रीऐक्टिव तरीके लागू किए जा सकते हैं, लेकिन ये तरीके स्टैंडर्ड एसेट मैनेजमेंट प्रोसेस से बाहर हो गए हैं. इसमें, "टोही" प्रोसेस का इस्तेमाल करना शामिल हो सकता है, जिसका इस्तेमाल सुरक्षा रिसर्चर करते हैं. ये रिसर्चर, वीडीपी और बग बाउंटी प्रोग्राम में हिस्सा लेते हैं. उदाहरण के लिए, मुफ़्त और ओपन सोर्स टूल का इस्तेमाल किया जा सकता है, जो इंटरनेट की सुविधा वाले आईपी रेंज या आपके संगठन से जुड़े डोमेन को स्कैन और उनकी गिनती करते हैं. बग बाउंटी रिकन के लिए Google पर की गई खोज से, आपको कई तरह के सुझाव और तरकीबें मिलेंगी. इनसे आपको अपने संगठन की ऐसी ऐसेट की पहचान करने में मदद मिलेगी जिनके बारे में आपको जानकारी नहीं थी.

जोखिम की आशंका को स्कैन करने के बुनियादी तरीके

अब आपको इस बात की पूरी जानकारी मिल गई है कि सुरक्षा से जुड़ी समस्याएं कहां ढूंढी जा सकती हैं, तो चलिए जानते हैं कि ऐसा करने का तरीका क्या है. अपने संगठन के संसाधनों पर निर्भर करते हुए आप कई लेवल पर पहुंच सकते हैं. हालांकि, जोखिम की आशंका की जानकारी देने वाले अपने प्रोग्राम के ज़रिए, आपको अपनी अंदरूनी सुरक्षा कोशिशों और बाहरी हैकिंग कम्यूनिटी के बीच संतुलन बनाए रखने की ज़रूरत होगी. हर संगठन के लिए यह बैलेंस अलग-अलग होता है. यह अंतर, उपलब्ध संसाधनों पर निर्भर करता है.

अपने टूल चुनें

जोखिम की आशंकाओं की पहचान करने के लिए कई अलग-अलग टूल हैं. जोखिम की आशंका को स्कैन करने वाले कुछ टूल मुफ़्त में उपलब्ध हैं, जबकि कुछ के लिए शुल्क देना पड़ता है. किस टूल का चुनाव करना है, यह आपकी व्यक्तिगत ज़रूरतों पर निर्भर करता है.

• आपके संगठन की ज़रूरी शर्तें
• हर टूल इन शर्तों को कितनी अच्छी तरह पूरा करता है
• अगर टूल से मिलने वाले फ़ायदे लागत (वित्तीय और लागू करने के तरीके) से ज़्यादा ज़्यादा होते हैं.

आपकी ज़रूरत के हिसाब से अलग-अलग टूल का आकलन करने के लिए, इस ज़रूरी टेंप्लेट (OpenDocument .ods, Microsoft Excel .xlsx) का इस्तेमाल किया जा सकता है. टेंप्लेट में, उदाहरण के तौर पर कुछ ज़रूरी शर्तों को शामिल किया गया है. हालांकि, आपको अपनी सुरक्षा, आईटी, और इंजीनियरिंग टीम से चर्चा करनी चाहिए. जोखिम की जानकारी देने वाला प्रोग्राम लॉन्च करने से पहले, आपको बाहर से दिखने वाली किसी भी एसेट (जैसे कि वेबसाइटें, एपीआई, मोबाइल ऐप्लिकेशन) के लिए जोखिम की आशंका को स्कैन करना होगा. बाहरी सुरक्षा शोधकर्ताओं को इन एसेट और सेवाओं की जांच करने के लिए न्योता देने से पहले, इस तरह के जोखिमों को आसानी से ढूंढने और उन्हें ठीक करने में मदद मिलेगी.

सेटअप स्कैन करें

जोखिम की आशंका का अपने-आप पता लगाने की सुविधा से कई समस्याओं का पता चल सकता है, लेकिन उनसे गलत जानकारी भी पैदा हो सकती है. इसलिए, यह ज़रूरी है कि जिन टीमों पर असर हुआ है उनके साथ नतीजों को शेयर करने से पहले, उनकी पुष्टि करने वाले संसाधन उपलब्ध हों. आपको ये प्रोसेस लागू करनी होंगी, ताकि यह पक्का किया जा सके कि स्कैन नियमित रूप से किया जा रहा हो. साथ ही, यह भी पक्का किया जा सके कि इन स्कैन के नतीजों पर असल में कार्रवाई की जा रही हो. यह हर संगठन के लिए अलग दिखेगा, लेकिन कम से कम आपको यह तय करना होगा कि:

• स्कैन की फ़्रीक्वेंसी
  • लगातार
  • हफ़्ते में एक बार
  • हर महीने
• कौनसी ऐसेट स्कैन की जा रही हैं
• क्रेडेंशियल
  • पुष्टि किए गए स्कैन और पुष्टि न किए गए स्कैन से मिली जानकारी
  • (संकेत: अगर आपने क्रेडेंशियल के साथ स्कैन नहीं किया, तो अपना वीडीपी शुरू करते समय एक सुरक्षा शोधकर्ता, क्रेडेंशियल से जांच करता है, तो आपको पहचानी गई गड़बड़ियों की बड़ी संख्या मिल सकती है)
• भूमिकाएं और ज़िम्मेदारियां
  • टीम के उन सदस्यों की पहचान करें जो स्कैन करने के लिए ज़िम्मेदार हैं
  • अगर ज़रूरी हो, तो रोटेशन सेट अप करें
• स्कैन के नतीजे
  • स्कैन के नतीजों की पुष्टि की जा रही है
  • पुष्टि किए गए जोखिमों के लिए बग फ़ाइल करना
  • गड़बड़ियां ठीक करने के लिए मालिकों की पहचान करना
  • बचा हुआ डेटा एक्सपोर्ट करने के लिए मालिकों से संपर्क करना

हम इस गाइड में बाद में गड़बड़ियां ठीक करना सेक्शन में, सुरक्षा से जुड़ी समस्याओं को ठीक करने का तरीका बताएंगे.

सुरक्षा की समीक्षा की प्रोसेस

जोखिम की आशंका को स्कैन करने की सुविधा, आपके संगठन में सुरक्षा से जुड़ी समस्याओं की बेहतर तरीके से पहचान करने का एक बेहतरीन तरीका है. हालांकि, सुरक्षा समीक्षा की प्रोसेस लागू करने से जोखिम की आशंकाओं को शुरुआत में ही सामने आने से रोका जा सकता है. इस गाइड में, सुरक्षा समीक्षा शब्द का मतलब ऐसी किसी भी स्थिति से है जिसमें आपकी सुरक्षा टीम के किसी सदस्य की मैन्युअल समीक्षा को ट्रिगर किया जाता है. आम तौर पर, इसमें किसी बदलाव को ब्लॉक करने का अधिकार भी शामिल होता है. ऐसा तब किया जाता है, जब आपको लगता है कि यह बदलाव बहुत जोखिम भरा है. अगर आपकी सुरक्षा टीम के पास जोखिम भरे बदलावों को ब्लॉक करने की सुविधा नहीं है, तब भी आपको जोखिम का रिकॉर्ड रखने के लिए प्रोसेस का इस्तेमाल करना होगा. इससे यह पक्का करने में मदद मिल सकती है कि जो भी बदलाव करने की कोशिश कर रहा है उसे इसमें शामिल जोखिम का पता है और वह गंभीरता से उस जोखिम को स्वीकार कर लेता है.

सुरक्षा समीक्षा की शर्तें

सुरक्षा की समीक्षाएं कब की जानी चाहिए? सुरक्षा जांच को ट्रिगर करने के लिए शर्तों का एक सेट तय करने से, यह पक्का करने में मदद मिलती है कि सभी लोग एक ही पेज पर हैं. नीचे ऐसे मामलों के कुछ उदाहरण दिए गए हैं जो सुरक्षा समीक्षा को ट्रिगर कर सकते हैं.

• उपयोगकर्ता के संवेदनशील डेटा से जुड़ी नई सुविधा का सुझाव दिया गया है
  • एक नई सुविधा, जिसकी मदद से उपयोगकर्ता मैप पर अपनी जगह की जानकारी शेयर कर सकते हैं
  • उपयोगकर्ताओं से संवेदनशील जानकारी मांगना, जैसे कि उनके घर का पता, जन्म की तारीख या फ़ोन नंबर
• मौजूदा सुविधाओं में अहम बदलाव किए गए हैं
  • मौजूदा उपयोगकर्ताओं का डेटा लेना और उसे नए तरीके से इस्तेमाल करना, ऐसा हो सकता है कि उपयोगकर्ता उन्हें ऑप्ट आउट करने का मौका दिए बिना उनकी उम्मीद न करें
  • पुष्टि करने, अनुमति देने, और सेशन मैनेजमेंट से जुड़ी किसी भी सुविधा में होने वाले बदलाव
• कंपनी के प्रोडक्शन एनवायरमेंट में हुए बदलाव
  • नेटवर्क कॉन्फ़िगरेशन में बदलाव, खास तौर पर ऐसे बदलाव जिनकी वजह से सेवाओं को बाहरी लोगों के साथ शेयर किया जा सकता है.
  • उपयोगकर्ता के संवेदनशील डेटा को मैनेज करने वाले नए सॉफ़्टवेयर का इंस्टॉलेशन
  • नए सिस्टम या सेवाएं तैयार करना
• नए वेंडर के साथ इंटरैक्ट करना या मौजूदा वेंडर के साथ काम करने का तरीका बदलना
  • ऐसे नए वेंडर को शामिल करना जो उपयोगकर्ता के संवेदनशील डेटा को मैनेज करेगा
  • किसी मौजूदा वेंडर के साथ काम करने के आपके तरीके में बदलाव होने की वजह से वेंडर, उपयोगकर्ता के संवेदनशील डेटा को मैनेज कर सकता है

यह पूरी सूची नहीं है, लेकिन इससे आपको यह सोचना चाहिए कि किस तरह के बदलावों के लिए सुरक्षा समीक्षा की ज़रूरत होनी चाहिए. सुरक्षा समीक्षा के लिए क्या करना ज़रूरी है और क्या नहीं, यह तय करने के बाद संगठन के मुख्य हिस्सेदारों से इस बारे में बात करें कि:

• हिस्सेदारों के पास मानदंडों की समीक्षा करने और उन पर सुझाव/राय देने का मौका होता है.
• हिस्सेदार इन शर्तों से सहमत हैं
• हिस्सेदार, सुरक्षा की समीक्षा का अनुरोध करने के लिए सहमत हैं

अपने संगठन के लिए, इस प्रोसेस को आसानी से पूरा करने के लिए, इस शर्त को ध्यान में रखें. साथ ही, सुरक्षा समीक्षा का अनुरोध करने का तरीका भी बताएं. उदाहरण के लिए, सुरक्षा टीम की निगरानी करने वाली सूची में गड़बड़ी की शिकायत करना.

सुरक्षा समीक्षा संसाधन

अपने-आप होने वाले स्कैन से अलग, सुरक्षा से जुड़ी समीक्षाएं, ज़्यादा रिसॉर्स के हिसाब से हो सकती हैं. हर सुरक्षा टीम के पास दिन में बहुत से कामों के लिए इतना ही समय होता है. इसलिए, आपको यह अंदाज़ा लगाना होगा कि आपकी शर्तों के हिसाब से सुरक्षा से जुड़ी कितनी समीक्षाएं जनरेट हो सकती हैं. अगर आपको लगता है कि आपकी टीम पूरी तरह से काम नहीं कर रही है, तो सुविधाओं के लॉन्च का इंतज़ार कर रहे लोग सुरक्षा टीम से नाराज़ हो जाएंगे. इससे संगठन में सांस्कृतिक बदलाव आ सकते हैं. इससे सुरक्षा टीम को पार्टनर के बजाय, ब्लॉकर के तौर पर देखा जा सकता है. अगर सुरक्षा की समीक्षा की प्रोसेस असरदार नहीं होती, तो कई लोग और टीमें इसे पूरी तरह से बायपास करने की कोशिश करेंगी. अगर आपके पास कम संसाधन हैं, तो सुरक्षा की समीक्षा करवाना ज़रूरी बनाने से जुड़ी शर्तों को कम करें. साथ ही, बचे हुए कुछ और जोखिम को स्वीकार करने के लिए तैयार रहें. अगर सुरक्षा जांच करने के लिए संसाधनों की कमी की वजह से घटनाएं होती हैं, तो इससे ज़्यादा सुरक्षा संसाधनों की ज़रूरत को सही ठहराने में मदद मिलेगी.

सुरक्षा से जुड़ी समीक्षाएं की जा रही हैं

जब बात यह तय करने की हो कि सुरक्षा से जुड़ी कौनसी समीक्षाएं देनी हैं और उनका परफ़ॉर्मेंस कैसा रखना है, तो आपको प्राथमिकता के हिसाब से सूची की ज़रूरत होती है. अपने संगठन के दूसरे लोगों के लिए, सुरक्षा समीक्षा का अनुरोध करने का एक स्टैंडर्ड तरीका बनाएं. इसमें, ऐसी किसी भी जानकारी के साथ समीक्षा का अनुरोध करें जिसकी ज़रूरत, संगठन के अन्य लोगों को प्राथमिकता देने के लिए होगी. उदाहरण के लिए, सवालों की सूची में जवाब शामिल करें. इसमें बदलाव से जुड़ी जानकारी दी गई है. इसमें बदलाव के बारे में खास जानकारी दी गई है और यह भी बताया गया है कि इससे उपयोगकर्ता के किस तरह के डेटा पर असर पड़ेगा. इन सवालों के जवाबों के आधार पर, संभावित सुरक्षा समीक्षाओं को ज़्यादा, मध्यम या कम जोखिम वाले बदलावों की अपने-आप कैटगरी में बांटा जा सकता है. अगर किसी बदलाव में ज़्यादा जोखिम है, तो आपको ज़्यादा बारीकी से सुरक्षा की समीक्षा करने की ज़रूरत पड़ सकती है. अगर किसी बदलाव से कम जोखिम है, तो बेहतर सुरक्षा समीक्षा प्रक्रिया लागू की जा सकती है. सुरक्षा समीक्षा की सूची को मैनेज करने की ज़िम्मेदारी अपनी टीम में रोटेशन सेट अप करने के बारे में सोचें. साथ ही, पक्का करें कि आपकी टीम के सदस्य नई सुरक्षा समीक्षाओं को लें और मौजूदा सुरक्षा समीक्षाओं की प्रोग्रेस को फ़ॉलो करें. सुरक्षा समीक्षा की असल प्रक्रिया, जांच की जा रही जानकारी के आधार पर अलग-अलग होगी. उदाहरण के लिए, आपके मोबाइल ऐप्लिकेशन में किसी नई सुविधा का इस्तेमाल करने के लिए, कोड की समीक्षा करने और संभावित जोखिम की पहचान करने के लिए किसी सुरक्षा इंजीनियर की ज़रूरत पड़ सकती है. हो सकता है कि इंस्टॉल किए जा रहे नए सॉफ़्टवेयर की समीक्षा की जाए, ताकि यह पक्का किया जा सके कि ऐक्सेस कंट्रोल सही तरीके से सेट अप किया गया है या नहीं. बाहरी वेंडर के साथ काम करना एक बिलकुल अलग प्रक्रिया हो सकती है. रेफ़रंस के लिए, Google के विक्रेता सुरक्षा आकलन के लिए पूछे गए सवालों की सूची को पढ़ें.

गड़बड़ियां ठीक करना

गड़बड़ियां ढूंढना ज़रूरी है, लेकिन सुरक्षा उनमें सुधार के बाद ही गड़बड़ियां ठीक होती हैं. अपने संगठन के लिए मौजूद जोखिमों को समझना अच्छी बात है, लेकिन जोखिम का बेहतर ढंग से समाधान कर पाना बेहतर होता है.

जोखिम की आशंका का मैनेजमेंट

जोखिम की आशंकाएं कई तरह के संसाधनों से आती हैं. इनमें, जोखिम की आशंकाओं की जांच और सुरक्षा से जुड़ी समीक्षाएं, तीसरे पक्ष की जांच और ऑडिट या सुरक्षा जांच करने वाले बाहरी लोग शामिल हैं. ये रिसर्चर, आपके वीडीपी के आधिकारिक तौर पर लॉन्च होने से पहले, आपको सहायता चैनल से सूचना देते हैं. आपके संगठन को नई और मौजूदा जोखिम की आशंकाओं को अलग-अलग कैटगरी में बांटने की ज़रूरत है. इससे यह पक्का किया जा सकेगा कि उन्हें सही हिस्सेदारों को बताया जाए, उन्हें सही प्राथमिकता दी जाए, और उन्हें समय पर ठीक किया जाए. अपना वीडीपी लॉन्च करने पर, जोखिम की आशंकाओं को मैनेज करने की प्रोसेस में आपके पास कमियों की एक नई स्ट्रीम होगी. इन जोखिम की आशंकाओं से निपटने के लिए मज़बूत प्रोसेस काफ़ी होती हैं. इससे यह ट्रैक करने में मदद मिलती है कि समस्या ठीक करने की दिशा में कितनी कार्रवाई की गई है. साथ ही, बाहरी सुरक्षा शोधकर्ताओं के अनुरोधों का जवाब देने में भी मदद मिलती है. जोखिम की आशंका को जल्द से जल्द प्राथमिकता देने और वीडीपी में हिस्सा लेने वाले लोगों को राहत की समयावधि के बारे में बताने से, सुरक्षा पर रिसर्च करने वालों के समुदाय में आपकी दिलचस्पी बढ़ेगी. साथ ही, आपके संगठन की सुरक्षा की छवि बेहतर होगी. नीचे दिए गए सेक्शन में, जोखिम की आशंका को मैनेज करने वाले प्रोग्राम के ऐसे कई पहलुओं के बारे में बताया गया है जिन्हें आपको वीडीपी को लॉन्च करने से पहले लागू करना होगा.

गंभीरता के मानक तय करें और समस्या को ठीक करने की समयावधि तय करें

जोखिम की आशंकाओं की गंभीरता और हर तरह की गंभीरता को ठीक करने की आदर्श समयावधि तय करने से, आपके संगठन के लिए मानक रूप से उम्मीदें तय करना आसान हो जाता है. अगर हर जोखिम का इलाज आपातकालीन स्थिति की तरह किया जाता है, तो आपका संगठन अपने संसाधन खत्म कर देगा और सुरक्षा टीम के प्रति गुस्सा घुल जाएगा. अगर हर जोखिम को कम प्राथमिकता दी जाती है, तो जोखिम की आशंकाओं को कभी ठीक नहीं किया जा सकता. इससे, उल्लंघन होने का खतरा बढ़ जाता है. हर संगठन के पास सीमित संसाधन होते हैं, इसलिए आपको गंभीरता की रैंकिंग तय करनी होगी. इस रैंकिंग से आपके संगठन को यह समझने में मदद मिलती है कि जोखिम किस तरह की है. साथ ही, हर गंभीर समस्या को ठीक करने का अनुमानित समय भी मिलता है. गंभीरता के दिशा-निर्देशों का एक सेट तैयार करें और सुझाव पाने के लिए इसे अपने संगठन के अहम हिस्सेदारों के साथ शेयर करें. उदाहरण के लिए, अगर गंभीरता के मानक तय करने में इंजीनियरिंग की मदद ली जाती है, तो इस बात की संभावना बढ़ जाती है कि वे इन मानकों को पूरा कर लें. साथ ही, तय समयावधि में जोखिम की आशंका को दूर करने के लिए, इन मानकों का पालन करने की संभावना भी ज़्यादा होगी. गंभीरता के ये दिशा-निर्देश, आपके कारोबार से जुड़े जोखिमों के आधार पर अलग-अलग हो सकते हैं. अपने संगठन पर सबसे ज़्यादा असर डालने वाले और असर डालने वाले खतरों के बारे में सोचें. साथ ही, गंभीरता की हर कैटगरी में आने वाली समस्याओं के उदाहरण शामिल करें. किसी वित्तीय संगठन की गंभीरता से जुड़े मानकों और उसे ठीक करने की समयावधि का उदाहरण नीचे दिया गया है.

समस्या की गंभीरता	ब्यौरा	बचा हुआ डेटा एक्सपोर्ट करने की समयावधि	उदाहरण
अहम	ऐसी समस्याएं जिनसे हमारे उपयोगकर्ताओं या हमारे कारोबार को खतरा हो सकता है.	मालिक: यह पक्का करने के लिए कि जोखिम की आशंका को ठीक करने के लिए मुख्य मालिक की पहचान आठ घंटे के अंदर हो जानी चाहिए. ज़रूरत पड़ने पर कॉल और पेज रिसॉर्स की सुविधा, कारोबार के खुले होने के समय के बाद भी कॉल करें. ठीक करें: समस्या अपने-आप ठीक हो जानी चाहिए या कम से कम तीन कामकाजी दिनों में जोखिम कम हो जाना चाहिए.	प्रोडक्शन डेटाबेस के साथ छेड़छाड़ करना, जिसमें उपयोगकर्ताओं के सभी वित्तीय रिकॉर्ड शामिल हों. एक हमलावर, जो हमारे निवेश के एल्गोरिदम, जैसे कि हमारे मालिकाना हक वाले निवेश एल्गोरिदम का ऐक्सेस हासिल कर लेता है. ऐसी घटना जिसमें कोई हमलावर हमारे इंटरनल नेटवर्क या संवेदनशील प्रोडक्शन सिस्टम का ऐक्सेस हासिल कर लेता है.
ज़्यादा	ऐसी समस्याएं जिनका फ़ायदा उठाए जाने पर काफ़ी नुकसान हो सकता है.	मालिक: मुख्य मालिक की पहचान एक कामकाजी दिन के अंदर हो जानी चाहिए. ठीक करें: 10 कामकाजी दिनों (~2 हफ़्ते) में.	जोखिम की आशंकाएं, जिनकी वजह से उपयोगकर्ता के संवेदनशील डेटा का ऐक्सेस या उसके काम करने के तरीके को ऐक्सेस करने में समस्या हो सकती है. जैसे, किसी व्यक्ति का किसी दूसरे उपयोगकर्ता से पैसे चुराने की क्षमता.
मीडियम	ऐसी समस्याएं जिनका फ़ायदा उठाना मुश्किल होता है या जिनसे सीधे तौर पर कोई नुकसान नहीं होता.	मालिक: पांच कामकाजी दिनों के अंदर मुख्य मालिक की पहचान हो जानी चाहिए. समस्या ठीक करें: 20 से 40 कामकाजी दिनों (~1-2 महीने) में.	अपने-आप काम करने वाले स्कैनर से पहचानी गई समस्याएं, जैसे कि सुरक्षा से जुड़े अपडेट के लिए पैच इस्तेमाल किए जाने की जानकारी. जानकारी ज़ाहिर करने से जुड़ी समस्याएं, जिनसे आगे की कार्रवाई में मदद मिल सकती है. उन समस्याओं को सीमित करने की दर जिनका फ़ायदा उठाया जा सकता है (जैसे, किसी उपयोगकर्ता के लिए लगातार पासवर्ड का अनुमान लगाने की सुविधा देना).
खराब	ऐसी समस्याएं जिनका असर कम से कम होता है. खास तौर पर, इनका इस्तेमाल उन समस्याओं को लॉग करने के लिए किया जाता है जिनके बारे में हमें पहले से पता है.	मालिक को ढूंढने या बताई गई समयावधि में समस्या ठीक करने की कोई ज़रूरत नहीं है.	ऐसी जानकारी ज़ाहिर करना जिससे कोई जोखिम न हो, लेकिन जानकारी को बाहरी लोगों तक पहुंचाना ज़रूरी न हो.

ग्रूमिंग बग

यहां हम बाल कटवाने के बारे में बात नहीं कर रहे हैं, हम यह पक्का करने के बारे में बात कर रहे हैं कि बग को सही तरीके से फ़ॉर्मैट किया जाए, ताकि उन्हें आसानी से ठीक किया जा सके. पिछली टेबल का इस्तेमाल दिशा-निर्देशों के तौर पर करें और अपनी गंभीरता की परिभाषाएं तय करें. इन डेफ़िनिशन का इस्तेमाल, गड़बड़ियों को अलग-अलग गंभीरता में बांटने और मालिकों को बताने के लिए किया जाता है.

हर जोखिम की गंभीरता को असाइन करने के साथ-साथ, आपको यह पक्का करना होगा कि आपके बग एक स्टैंडर्ड फ़ॉर्मैट में हों, ताकि टीम को प्रोसेस करना आसान हो जाए. जोखिम की आशंकाएं, जोखिम की आशंका को मैनेज करने से जुड़ी आपकी प्रोसेस में कई तरह के फ़ॉर्मैट में शामिल होंगी. जैसे, अपने-आप मिलने वाले स्कैनर के नतीजे या सुरक्षा समीक्षाओं से मिले मैन्युअल तरीके से लिखे गए दस्तावेज़. हर एक जोखिम को एक मानक फ़ॉर्मैट में बदलने में समय देने से, पाने वाली टीम के लिए समस्या को जल्दी समझने और ठीक करने की संभावना बढ़ जाएगी.

आपके संगठन और उसमें असाइन की गई गड़बड़ियों को ठीक करने में मालिकों की मदद करने के लिए, कौनसी जानकारी सबसे ज़्यादा ज़रूरी है, इस आधार पर यह फ़ॉर्मैट या टेंप्लेट अलग-अलग हो सकता है. हालाँकि, यहां उदाहरण के तौर पर एक टेंप्लेट दिया गया है. बाद में, रिसर्च करने वालों के लिए जोखिम की आशंका ज़ाहिर करने वाले प्रोग्राम को सबमिट करने वाला फ़ॉर्म बनाते समय, इस टेंप्लेट का फिर से इस्तेमाल किया जा सकता है.

शीर्षक: <एक पंक्ति में समस्या का ब्यौरा, आम तौर पर जोखिम किस तरह का है और किस तरह की एसेट/सेवा/वगैरह पर असर पड़ा है; वैकल्पिक तौर पर गंभीरता शामिल करें या अपने समस्या ट्रैकर में एक फ़ील्ड की गंभीरता मैप करें> खास जानकारी: <सुरक्षा की कमी का ब्यौरा और यह क्यों ज़रूरी है> फिर से प्रोडक्शन के कदम: <चरण-दर-चरण से जुड़े निर्देश इस जोखिम से किस तरह जुड़े होंगे, इस समस्या से जुड़े किस तरह के असर को सीधे तौर पर कैसे असर होगा, इस पर क्या असर होगा: इस समस्या को किस तरह ठीक किया जाएगा किसी भी तरह की चेतावनी को किस तरह ठीक किया जाएगा इस तरह के जोखिम को कैसे कम किया जा सकता है

यहां ज़्यादा गंभीरता के संभावित जोखिम का एक उदाहरण दिया गया है:

टाइटल: [HIGH] प्रोफ़ाइल पेजों में असुरक्षित डायरेक्ट ऑब्जेक्ट रेफ़रंस खास जानकारी: हमारे ऐप्लिकेशन के प्रोफ़ाइल पेजों पर एक IDOR मिला है. इससे किसी भी उपयोगकर्ता को बिना अनुमति के किसी दूसरे उपयोगकर्ता की प्रोफ़ाइल देखने और उसमें बदलाव करने का ऐक्सेस मिल जाता है. इसमें, उपयोगकर्ता का पूरा नाम, घर का पता, फ़ोन नंबर, और जन्म की तारीख शामिल है. हमने लॉग की समीक्षा कर ली है और ऐसा लगता है कि इस समस्या का अभी तक फ़ायदा नहीं हुआ है. इस समस्या के बारे में इंटरनल को पता चला था. रीप्रोडक्शन का तरीका:

1. जिस मोबाइल डिवाइस पर ऐप्लिकेशन इंस्टॉल है, उस पर आने वाले ट्रैफ़िक को रोकने के लिए, प्रॉक्सी सेट अप करें, जैसे कि बर्प सुइट.
2. अपने प्रोफ़ाइल पेज पर जाएं और इससे जुड़े एचटीटीपी अनुरोध को रोकें.
3. profileID=###### को बदलकर profileID=000000 (यह एक टेस्ट उपयोगकर्ता है) बनाएं और एचटीटीपी अनुरोध भेजें.
4. ऐप्लिकेशन, उपयोगकर्ता 000000 की प्रोफ़ाइल दिखाएगा और आप उसकी जानकारी देख सकेंगे और उसमें बदलाव कर सकेंगे.

हमले की स्थिति / असर: कोई भी उपयोगकर्ता, दूसरे उपयोगकर्ता की प्रोफ़ाइल देखने और उसमें बदलाव करने के लिए, इस जोखिम की आशंका का इस्तेमाल कर सकता है. सबसे खराब स्थिति में, कोई हमलावर हमारे पूरे सिस्टम में, हर उपयोगकर्ता की प्रोफ़ाइल की जानकारी वापस पाने की प्रोसेस को ऑटोमेट कर सकता है. हमें नहीं लगता कि अभी तक इसका इस्तेमाल नहीं हुआ है, लेकिन यह ज़रूरी है कि हम इसे सामान्य गंभीर समस्या मानें. अगर हमें शोषण के सबूत मिलते हैं, तो यह गंभीर और गंभीर हो सकता है. समाधान करने के तरीके: सर्वर साइड जांच लागू करें, ताकि यह पक्का किया जा सके कि अनुरोध करने वाले उपयोगकर्ता के पास, प्रोफ़ाइल आईडी की वैल्यू के ज़रिए अनुरोध की गई प्रोफ़ाइल को देखने या उसमें बदलाव करने का ऐक्सेस होना चाहिए. उदाहरण के लिए, अगर ऐलिस ने लॉग इन किया है और उनकी प्रोफ़ाइल आईडी 123456 है, लेकिन ऐलिस ने प्रोफ़ाइल आईडी 333444 का अनुरोध किया है, तो उपयोगकर्ता को गड़बड़ी दिखेगी और दूसरे उपयोगकर्ता की प्रोफ़ाइल ऐक्सेस करने की कोशिश को लॉग करना चाहिए. IDOR पर ज़्यादा जानकारी पाने और इसे ठीक करने के तरीके के बारे में ज़्यादा जानने के लिए, कृपया इस गड़बड़ी पर OWASP की सामग्री देखें.

अलग-अलग सोर्स से मिली जोखिम की आशंकाओं को अपने-आप अपने स्टैंडर्ड फ़ॉर्मैट में बदलने के तरीके खोजकर, समय और मैन्युअल तरीके से मेहनत की जा सकती है. जैसे-जैसे ज़्यादा जोखिम पैदा होता है, वैसे-वैसे आपको समस्या ठीक करने के तरीकों में सामान्य थीम मिल सकती हैं. गड़बड़ी के सामान्य फ़ॉर्मैट वाले टेंप्लेट के अलावा, हो सकता है कि आप जोखिम की आम गड़बड़ियों के लिए और भी टेंप्लेट बनाना चाहें.

मालिकों को ढूंढा जा रहा है

जोखिम की आशंका को मैनेज करने का सबसे मुश्किल काम, गड़बड़ियों को ठीक करने के लिए मालिकों की पहचान करना है. साथ ही, समय-समय पर गड़बड़ियों को ठीक करने के लिए संसाधनों का इस्तेमाल करना है. अगर आपने एसेट मैनेजमेंट प्रोसेस को सेट अप कर लिया है, तो यह थोड़ा आसान हो जाएगा. अगर ऐसा नहीं है, तो यह आपको ऐसा करने के लिए प्रेरित कर सकता है. आपके संगठन में काम करने वाले लोगों के आकार के आधार पर, मालिक को ढूंढना काफ़ी आसान या मुश्किल हो सकता है. जैसे-जैसे आपका संगठन बढ़ता है, वैसे-वैसे यह पता लगाने की कोशिश भी बढ़ती जाती है कि ऐसी नई सुरक्षा समस्याओं को ठीक करने में कौन ज़िम्मेदार है. ऑपरेशनल ऑन-ड्यूटी रोटेशन लागू करने के बारे में सोचें. जो भी काम पर है वह असाइन नहीं किए गए जोखिम की आशंकाओं की समीक्षा करने, मालिकों को ट्रैक करने, और गंभीरता के मुताबिक प्राथमिकता तय करने के लिए ज़िम्मेदार होता है. भले ही, आप यह पता कर लें कि जोखिम की आशंका को ठीक करने के लिए कौन ज़िम्मेदार है और उन्हें गड़बड़ी के लिए असाइन किया जा सकता हो, लेकिन आपको उन्हें इस समस्या को ठीक करने के लिए मनाना होगा. यह तरीका टीम या व्यक्ति के हिसाब से अलग-अलग हो सकता है. यह इस बात पर भी निर्भर करता है कि वे किन दूसरे आइटम पर काम कर रहे हैं. अगर आपने संगठन के लिए, गंभीरता से जुड़े मानकों और समस्या को ठीक करने की समयावधि के हिसाब से खरीदारी कर ली है, तो उनके बारे में जानकारी ली जा सकती है. हालांकि, कभी-कभी किसी व्यक्ति को गड़बड़ी ठीक करने के लिए, ज़्यादा ज़ोर-शोर से काम करना पड़ सकता है. जोखिम की आशंकाओं को दूर करने के लिए, यहां कुछ सामान्य सुझाव दिए गए हैं:

• ऐसा होने की वजह बताएं: जब किसी व्यक्ति को जोखिम की आशंका हो, तो आम तौर पर उम्मीद के मुताबिक काम नहीं हो सकता. बताएं कि इस समस्या को समय पर ठीक करना क्यों ज़रूरी है (उदाहरण के लिए, असर / हमले की स्थिति) और पक्का करें कि मालिक इस बात को समझ गया हो.
• जानकारी इकट्ठा करें: कुछ मामलों में, सिर्फ़ एक व्यक्ति के पास गड़बड़ी को ठीक करने के लिए ज़रूरी जानकारी होती है. साथ ही, यह भी हो सकता है कि उसके पास ऐसे दूसरे काम भी हों जिन पर वे काम कर रहे हों. समय निकालें और इन समस्याओं के बारे में जानें - हो सकता है कि आने वाले समय में, इस जोखिम को ठीक करने के बजाय दूसरे काम ज़्यादा अहम हों. राहत की समयावधि में, सहानुभूति दिखाने और ज़रूरत के हिसाब से सही समय पर सूचना देने से, लोगों की अच्छी भावनाएँ हासिल करने में मदद मिलती है. साथ ही, जिन लोगों को जोखिम की आशंकाओं को दूर करना होता है उनके साथ आपका रिश्ता मज़बूत होता है. बस इस बात का ध्यान रखें कि बहुत ज़्यादा छूट न दें, वरना आपका संगठन, बचा हुआ डेटा वापस लेने में लगने वाले समय को गंभीरता से नहीं लेगा.
• इसका तरीका बताएं: अगर आपने बग में सुधार से जुड़ी सलाह शामिल की है, तो हो सकता है कि समस्या ठीक करने वाला व्यक्ति उलझन में हो या उसे बग ठीक करने का तरीका जानने में मदद की ज़रूरत हो. अगर उन्हें इस समस्या को ठीक करने का तरीका जानने में मदद चाहिए, तो उनकी मदद करें. मालिकों की मदद किए बिना सिर्फ़ उन पर गड़बड़ियां फेंकना, सुरक्षा टीम के साथ संगठन के रिश्ते पर बुरा असर डालता है. दूसरों की ज़्यादा से ज़्यादा मदद करने से, उन्हें मौजूदा और आने वाले समय में होने वाले जोखिमों को ठीक करने में मदद मिलेगी. साथ ही, दूसरों को सीखने में भी मदद मिलेगी.
• अपने अनुरोध को स्वीकार करें: अलग-अलग टीमों और लोगों के पास काम के अनुरोधों को स्वीकार करने और उन्हें प्राथमिकता देने की मौजूदा प्रोसेस हो सकती हैं. कुछ टीमें चाहती हैं कि आने वाले सभी अनुरोध उनके मैनेजर के ज़रिए आएं. दूसरे लोग यह चाहेंगे कि मदद के अनुरोध, सामान्य फ़ॉर्मैट में सबमिट किए जाएं. कुछ प्रोग्राम सिर्फ़ उन चीज़ों पर काम करेंगे जिन्हें स्प्रिंट में पहले से तय किया गया है. जो भी हो, अपने अनुरोध को उस फ़ॉर्मैट के मुताबिक बनाने में थोड़ा समय लें जो आम तौर पर टीम या व्यक्ति, मदद के लिए अनुरोध करने के लिए इस्तेमाल करता है. इससे आपके अनुरोध को प्राथमिकता देने और उस पर कार्रवाई किए जाने की संभावना बढ़ जाएगी.
• आखिरी उपाय के तौर पर आगे बढ़ाएं: अगर आपने ऊपर बताए गए सभी तरीकों को आज़मा लिया है और जिस व्यक्ति या टीम को जोखिम की आशंका को ठीक करने का काम दिया गया है उसे सुरक्षा से जुड़ी किसी गंभीर समस्या को ठीक करने में समय नहीं मिलेगा, तो ज़रूरत पड़ने पर अपने मैनेजमेंट को आगे बढ़ाने के बारे में सोचें. यह हमेशा एक आखिरी उपाय होना चाहिए, क्योंकि यह उस व्यक्ति या टीम के साथ आपके रिश्ते को नुकसान पहुंचा सकता है जिसकी शिकायत की गई है.

असल वजहों का विश्लेषण

अलग-अलग जोखिमों को ढूंढने और उन्हें ठीक करने के अलावा, मूल वजह का विश्लेषण (आरसीए) करने से, आपको व्यवस्थित सुरक्षा से जुड़ी समस्याओं की पहचान करने और उन्हें ठीक करने में मदद मिल सकती है. सभी के पास सीमित संसाधन हैं. इसलिए, इनमें से किसी भी चरण को छोड़ा जा सकता है. हालांकि, अपने जोखिम की आशंका वाले डेटा के रुझानों का विश्लेषण करने के लिए समय देने और गंभीर और ज़्यादा गंभीरता वाली गड़बड़ियों की जांच करने से समय की बचत हो सकती है और लंबे समय में जोखिम कम हो सकता है. उदाहरण के तौर पर, मान लीजिए कि आपको अपने ऐप्लिकेशन में बार-बार एक ही तरह के जोखिम (उदाहरण के लिए, इंटेंट रीडायरेक्ट) दिखते हैं. आप तय करें कि आपके ऐप्लिकेशन में इस जोखिम को पेश करने वाली टीमों से बात करने का फ़ैसला लिया जाता है और उनमें से ज़्यादातर को यह समझ नहीं आता है कि इंटेंट रीडायरेक्शन क्या है, यह क्यों ज़रूरी है या उसे कैसे रोका जाए. आपने अपने संगठन में डेवलपर को इस जोखिम के बारे में समझाने के लिए एक बातचीत और एक गाइड तैयार की है. यह जोखिम शायद पूरी तरह से खत्म नहीं होगा, लेकिन इसके दिखने की दर घट सकती है. वीडीपी लॉन्च करने पर, किसी तीसरे पक्ष से मिली हर जोखिम की आशंका को आपकी मौजूदा इंटरनल सुरक्षा प्रोसेस के ज़रिए सुलझाया जाता है. वीडीपी की गड़बड़ियों पर आरसीए करने से, आपको इस बारे में और अहम जानकारी मिलेगी कि सुरक्षा प्रोग्राम को सही तरीके से कैसे बेहतर बनाया जा सकता है.

वीडियो की पहचान और उस पर कार्रवाई

डिटेक्शन और रिस्पॉन्स का मतलब ऐसे टूल और प्रोसेस से है जिनका इस्तेमाल, आपके संगठन के ख़िलाफ़ हो सकने वाले हमलों का पता लगाने और उनका जवाब देने के लिए किया जाता है. ऐसा खरीदे गए या खुद से बनाए गए समाधान के रूप में किया जा सकता है. ये समाधान, संदिग्ध व्यवहार की पहचान करने के लिए डेटा का विश्लेषण करते हैं. उदाहरण के तौर पर, ग्रूमिंग से जुड़ी गड़बड़ियां सेक्शन में, जब भी कोई उपयोगकर्ता किसी दूसरे उपयोगकर्ता की प्रोफ़ाइल को बिना अनुमति के ऐक्सेस करने की कोशिश करता है, तब हमने हर बार लॉग इन करने के बारे में बात की. यह मुमकिन है कि आपको कोई सिग्नल या चेतावनी दिखे. यह तब जनरेट होता है, जब कोई उपयोगकर्ता कुछ ही समय में, दूसरे उपयोगकर्ता की प्रोफ़ाइल ऐक्सेस करने की बहुत सारी गलत कोशिश कर रहा है. आप उस उपयोगकर्ता को किसी खास अवधि के लिए, आपकी किसी भी सेवा को ऐक्सेस करने से रोकने की प्रोसेस को ऑटोमेट भी कर सकते हैं. इसके अलावा, स्थिति की समीक्षा पूरी होने और मैन्युअल तरीके से ऐक्सेस वापस लाने तक, आप ऐसा अनिश्चित समय के लिए कर सकते हैं. अगर आपके पास पहले से ही जांच करने और जवाब देने के तरीके नहीं हैं, तो किसी विशेषज्ञ सलाहकार के साथ काम करें. इससे आपको अपने संगठन के लिए डिजिटल फ़ोरेंसिक और इंसिडेंट रिस्पॉन्स (डीएफ़आईआर) प्रोग्राम बनाने में मदद मिलेगी. अगर गतिविधि का पता लगाने और जवाब देने के तरीकों पर पहले से ही कार्रवाई की गई है, तो इंटरनेट से जुड़े हमले की जगहों पर पांच, दस या सौ से भी ज़्यादा सुरक्षा रिसर्चर की जांच करने के नतीजों के बारे में सोचें. इसका असर आपके मौजूदा किसी भी आईडीएस/आईपीएस (घुसपैठ की पहचान और रोकथाम के सिस्टम) पर काफ़ी असर पड़ सकता है.

ये खतरे हो सकते हैं:

• चेतावनियों का ओवरलोड: चेतावनियां या सिग्नल की बहुत ज़्यादा बाढ़, जो नुकसान पहुंचाने वाले हमलों जैसे लगते हैं, लेकिन असल में ये सामान्य हैं और इन्हें मंज़ूरी मिली होती है. ये टेस्ट आपके वीडीपी में हिस्सा ले रहे सुरक्षा शोधकर्ताओं की होती है. इतना ज़्यादा शोर पैदा किया जा सकता है कि असली हमलों और सही सुरक्षा जांचों के बीच अंतर कर पाना मुश्किल हो जाता है.
• घटना पर प्रतिक्रिया के लिए गलत अलार्म: अगर आपने शनिवार को रात 2:00 बजे उस पेज पर लोगों को प्रोसेस करने की सुविधा दी है, तो वे खुद को ऐसे उल्लंघन के बारे में पता लगाने और जांच करने में खुश नहीं होंगे जो असल में किसी सुरक्षा शोधकर्ता ने सही जांच की है.
• सुरक्षा से जुड़ी रिसर्च करने वाले लोगों को ब्लॉक करना: अगर आपके पास एग्रेसिव आईपीएस (घुसपैठ की रोकथाम के लिए सिस्टम) मौजूद हैं, तो हो सकता है कि आपके पास सुरक्षा से जुड़ी रिसर्च करने वाले उस व्यक्ति का आईपी पता ब्लॉक हो जाए जो स्कैन, मैन्युअल टेस्ट वगैरह करने के लिए जोखिम की आशंकाओं का पता लगाकर आपको उनकी शिकायत करता है. खास तौर पर, वीडीपी के मामले में, अगर किसी सुरक्षा रिसर्चर को जांच के पांच मिनट के बाद ब्लॉक कर दिया जाता है, तो हो सकता है कि रिसर्च करने वाले व्यक्ति की दिलचस्पी कम हो जाए और वह दूसरे संगठन के प्रोग्राम पर फ़ोकस कर दे. इसकी वजह से, सुरक्षा पर रिसर्च करने वालों को आपके प्रोग्राम में शामिल होने की संभावना कम हो जाती है. इससे जोखिम की संभावना बढ़ जाती है और जोखिम की आशंका बढ़ जाती है. हालांकि, शायद आप अपने आईपीएस को छिपाना न चाहें, लेकिन ऐसे दूसरे तरीके हैं जिनसे रिसर्च करने वालों को नुकसान पहुंचने के जोखिम को कम किया जा सकता है.

इन जोखिमों को कैसे ठीक किया जाए, यह काफ़ी हद तक इस बात पर निर्भर करता है कि बाहरी सुरक्षा पर रिसर्च करने वालों के साथ काम करने के लिए, आपको कौनसा तरीका अपनाना है. अगर आपको ब्लैक बॉक्स स्टाइल की जांच के लिए, असली हमलों को सिम्युलेट करना है, तो शायद आपको कुछ न करना हो. इस मामले में, रिसर्च करने वाले का ट्रैफ़िक चेतावनियां जनरेट करेगा. इसके बाद, आपकी टीम, जांच करने और उसके हिसाब से जवाब देने के लिए कार्रवाई कर सकती है. इससे आपकी टीम को असली हमलों जैसे लगने वाले हमलों का जवाब देने की प्रैक्टिस करने में मदद मिलेगी. हालांकि, इससे सुरक्षा पर रिसर्च करने वालों की दिलचस्पी कम हो सकती है. खास तौर पर तब, जब उन्हें जांच करने से रोका गया हो. इसका नतीजा यह भी हो सकता है कि सही टेस्टिंग की जांच में समय बिताने के दौरान कोई असली हमला न हो पाए. अगर आपको स्लेटी बॉक्स के बारे में ज़्यादा जानकारी चाहिए, तो सुरक्षा से जुड़ी रिसर्च करने वालों के साथ मिलकर काम करें. इससे वे टेस्टिंग ट्रैफ़िक की पहचान खुद कर पाएंगे. इससे आपको ट्रैफ़िक को वाइटलिस्ट में शामिल किया जा सकेगा. इसके अलावा, टेस्ट और उससे मिलने वाली चेतावनियों से मिलने वाले ट्रैफ़िक को भी फ़िल्टर किया जा सकेगा. आपकी टीम असली हमलों और मंज़ूर किए गए जांचों के बीच अंतर कर पाएगी. साथ ही, रिसर्च करने वाले लोगों को घुसपैठ की रोकथाम के लिए बने सिस्टम से, जोखिम की आशंकाओं का पता लगाने और उनकी शिकायत करने का विकल्प मिलेगा. कुछ संगठन, सुरक्षा शोधकर्ताओं से यूनीक आइडेंटिफ़ायर के लिए आवेदन करने के लिए फ़ॉर्म सबमिट करने के लिए कहते हैं. इसे रिसर्चर के जनरेट किए गए अनुरोधों के हेडर में अटैच किया जा सकता है. इसकी मदद से संगठन, रिसर्च करने वाले व्यक्ति के लिए ट्रैफ़िक को व्हाइटलिस्ट में शामिल कर पाता है. साथ ही, इससे यह भी पता चल पाता है कि क्या रिसर्चर, टेस्टिंग के लिए तय दायरे से आगे बढ़कर काम कर रहा है या नहीं. अगर ऐसा होता है, तो रिसर्चर से संपर्क करें और उन्हें तब तक के लिए रोकने के लिए कहें, जब तक आप दोनों साथ मिलकर टेस्टिंग प्लान पर काम न कर लें.