A स्पूफिंग शिकायत एक लीड है, संपूर्ण तकनीकी निष्कर्ष नहीं। रिपोर्टर ने एक भ्रामक प्रदर्शन नाम, एक समान दिखने वाला पता, एक अग्रेषित संदेश या एक समझौता किया हुआ वैध खाता देखा होगा। उन्होंने जो देखा उसे संरक्षित करके, गुम हुए सबूतों की पहचान करके और किसी भी प्रभावित व्यावसायिक कार्रवाई की सुरक्षा करके जवाब दें। डोमेन नीति को केवल इसलिए न बदलें क्योंकि स्क्रीनशॉट में कंपनी का नाम है।
सबसे छोटे उपयोगी साक्ष्य सेट एकत्र करें
जब भी संभव हो किसी स्वीकृत सुरक्षित चैनल का उपयोग करके मूल संदेश, अनुमानित प्राप्ति समय, प्रभावित मेलबॉक्स और अनुरोधित कार्रवाई का विवरण मांगें। संपादन से पहले मूल को सुरक्षित रखें। रिकॉर्ड करें कि इसकी आपूर्ति किसने की, इसे कब प्राप्त किया गया और क्या यह सीधे प्राप्तकर्ता से आया या किसी मध्यस्थ के माध्यम से। अग्रेषित निकाय उन शीर्षकों को छोड़ सकता है जो जांच के लिए आवश्यक हैं।
मूल साक्ष्य को उचित पहुंच नियंत्रण में रखें। एक अलग साझाकरण प्रतिलिपि बनाएं जो प्रासंगिक पहचान फ़ील्ड को बनाए रखते हुए अनावश्यक प्राप्तकर्ता विवरण, व्यक्तिगत सामग्री या असंबंधित अनुलग्नकों को हटा देती है। दोनों फाइलों को हैश करें और संपादनों को दस्तावेजित करें ताकि समीक्षक समझ सके कि उनके बाइट्स अलग-अलग क्यों हैं। हैश बाँधते हैं एक अभिलिखित बाइट्स के लिए; वे यह साबित नहीं करते कि सामग्री प्रामाणिक है या प्रेषक की सही पहचान की गई थी।
विश्वसनीय प्रमाणीकरण साक्ष्य की पहचान करें
वह सिस्टम ढूंढें जिसने संदेश प्राप्ति के समय उसका मूल्यांकन किया। एक Authentication-Results फ़ील्ड केवल अपनी स्थापित ट्रस्ट सीमा के भीतर ही सार्थक है, जैसा कि RFC 8601 बताता है। प्रमाणीकरण परिणाम. किसी जेनरेटेड या अविश्वसनीय हेडर को रिसीवर अवलोकन में केवल इसलिए प्रमोट नहीं किया जाना चाहिए क्योंकि यह एक वैध प्रारूप का उपयोग करता है।
तुलना करें से, लिफाफा और DKIM व्यावसायिक अनुमोदन के साथ पासिंग हस्ताक्षर को मिलाए बिना पहचान। DMARC सभी प्रकार के प्रतिरूपण के बजाय संरेखित डोमेन प्रमाणीकरण को संबोधित करता है। RFC 9989. यदि मूल संदेश या विश्वसनीय लॉग अनुपलब्ध हैं, तो परिणाम को अनसुलझा रखें और वर्णन करें कि कौन से अतिरिक्त साक्ष्य इसे बदल देंगे।
एक काल्पनिक घटना बही बनाएँ
DEMO-COMPLAINT-01 मामले को पढ़ाने के लिए, मान लें कि एक शिकायतकर्ता दृश्यमान billing@brand-pay.test के साथ भुगतान-परिवर्तन अनुरोध की रिपोर्ट करता है। वास्तविक संदेश बाइट्स, रिसीवर टाइमस्टैम्प, विश्वसनीय प्रमाणीकरण परिणाम और ग्राहक विवरण प्रदान नहीं किए जाते हैं। मूल हैश को अनुपलब्ध के रूप में रिकॉर्ड करें, आविष्कृत डाइजेस्ट के रूप में नहीं। प्रासंगिक साक्ष्य प्राप्त होने तक वर्गीकरण अनंतिम रहता है।
प्रस्तावित अगली कार्रवाइयों को अलग से निर्दिष्ट करें: मेल संचालन अनुमोदित मूल निर्यात और विश्वसनीय प्राप्ति संदर्भ प्राप्त करता है; वित्त किसी ज्ञात चैनल के माध्यम से अनुरोध का सत्यापन करता है; घटना का नेतृत्व किसी भी आवश्यक साझाकरण या रोकथाम को अधिकृत करता है। ये उदाहरणात्मक भूमिकाएँ हैं, न कि वास्तविक लोग जिन्होंने कार्यभार स्वीकार किया।
बाद की वास्तविक साझाकरण प्रतिलिपि के लिए, मूल संदर्भ, प्रत्येक संपादित फ़ील्ड, उद्देश्य, प्राप्तकर्ता, अनुमोदन और परिणामी फ़ाइल हैश को लॉग करें। मूल को अपरिवर्तनीय रखें. एक बदला हुआ हैश बदले हुए बाइट्स की पहचान कर सकता है, लेकिन यह स्थापित नहीं कर सकता कि संदेश किसने लिखा है या हिरासत की एक श्रृंखला जो कभी रिकॉर्ड नहीं की गई थी। इस लिखित उदाहरण के लिए कोई मूल फ़ाइल, संशोधित नमूना, हैश गणना या बाहरी घटना कार्रवाई नहीं की गई थी।
एक सीमित निष्कर्ष के साथ उत्तर दें
एक उपयोगी स्वीकृति बताती है कि क्या प्राप्त हुआ है, क्या अज्ञात है और कौन जाँच कर रहा है। किसी आपूर्तिकर्ता पर आरोप लगाने या यह वादा करने से बचें कि पहचान से पहले समस्या का समाधान हो जाएगा और साक्ष्य उस निष्कर्ष का समर्थन करेंगे। यदि पैसा या साख खतरे में हो, तो साक्ष्य संग्रह जारी रहने तक संगठन की घटना प्रक्रिया का तुरंत पालन करें। एफबीआई भुगतान अनुरोधों और खाता परिवर्तनों के स्वतंत्र सत्यापन की अनुशंसा करती है। एफबीआई मार्गदर्शन.
प्रत्येक गुम वस्तु को एक मालिक और अगली कार्रवाई दें। मेल टीम रिसीवर लॉग पुनर्प्राप्त कर सकती है, व्यावसायिक टीम अनुरोध को सत्यापित कर सकती है और सुरक्षा नेतृत्व रोकथाम का समन्वय कर सकता है। बाहरी साझाकरण को स्वीकृत दायरे में रखें, खासकर जब मूल में संवेदनशील जानकारी हो।
केवल साक्ष्य द्वारा समर्थित निष्कर्षों को बंद करें। एक पुष्टि किए गए समान दिखने वाले अनुरोध को वर्गीकृत किया जा सकता है जबकि प्रदाता एट्रिब्यूशन अनसुलझा रहता है। मरम्मत किया गया वैध प्रेषण मार्ग व्यावसायिक हानि का समाधान किए बिना प्रमाणीकरण दोष को बंद कर सकता है। अंतिम घटना पैकेज में उन अंतरों को सुरक्षित रखें ताकि अगला समीक्षक आंशिक निष्कर्ष को पूर्ण समाधान समझने की गलती न करे।
निष्कर्षों को साक्ष्य के भीतर रखें
उदाहरण रक्षात्मक निर्णय सहायता हैं, वास्तविक लोगों या वर्तमान प्रदाताओं के खिलाफ देखे गए आरोप नहीं। प्रमाणीकरण साक्ष्य, व्यवसाय सत्यापन और एट्रिब्यूशन को अलग से रखें। वर्तमान प्रोटोकॉल स्रोत डोमेन सत्यापन और विश्वसनीय परिणाम सीमाओं का वर्णन करते हैं; वे गुम हुए खाते के साक्ष्य उपलब्ध नहीं कराते हैं या किसी आरोप के प्रकाशन को अधिकृत नहीं करते हैं।