व्यावसायिक ईमेल समझौता: पहचानें कि किस पहचान का दुरुपयोग किया गया

पहचान से शुरुआत करें, घटना के लेबल से नहीं

व्यावसायिक ईमेल समझौता यह एक हानिकारक व्यावसायिक परिदृश्य का वर्णन करता है, न कि किसी अद्वितीय ईमेल प्रमाणीकरण परिणाम का। एक भ्रामक अनुरोध एक प्रतिरूपण डोमेन, एक समझौता किए गए आपूर्तिकर्ता मेलबॉक्स, एक दुरुपयोग किए गए आंतरिक खाते या वैध भेजने वाले बुनियादी ढांचे का उपयोग करने वाले अनधिकृत एप्लिकेशन से आ सकता है। जांच से यह स्थापित होना चाहिए कि कौन सी पहचान प्रस्तुत की गई थी, किस प्रणाली ने इसे प्रमाणित किया था और प्राप्तकर्ता का मानना ​​था कि यह किस व्यवसाय प्राधिकरण का प्रतिनिधित्व करता है। उस अलगाव के बिना, एक टीम गलत नियंत्रण की मरम्मत कर सकती है जबकि अंतर्निहित जोखिम बना रहता है।

The IC3 क्लाउड-आधारित ईमेल सलाह, दिनांक 6 अप्रैल, 2020, वर्णन करता है कि कैसे समझौता किए गए क्लाउड ईमेल खाते बीईसी का समर्थन कर सकते हैं और स्वतंत्र सत्यापन और खाता सुरक्षा की सिफारिश करते हैं। यह पृष्ठभूमि मार्गदर्शन है, किसी वर्तमान घटना का साक्ष्य नहीं। माइक्रोसॉफ्ट का समझौता-खाता मार्गदर्शन इसी तरह Microsoft 365 में मेलबॉक्स दुरुपयोग और जांच का भी वर्णन करता है। कोई भी स्रोत यह स्थापित नहीं करता है कि काल्पनिक अभ्यास में चर्चा किए गए किसी भी खाते से वास्तव में समझौता किया गया है।

अनुरोध सुरक्षित रखें और व्यावसायिक कार्रवाई रोकें

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

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

एक पहचान स्टैक का निर्माण करें

दृश्यमान प्रदर्शन नाम सूचीबद्ध करें, पते से पार्स किया गया, उत्तर-पता पता, लिफाफा भेजने वाला, DKIM डोमेन पर हस्ताक्षर, रिसीवर प्रमाणीकरण परिणाम और कथित व्यावसायिक भूमिका। मेलबॉक्स या एप्लिकेशन खाता केवल तभी जोड़ें जब अधिकृत जांच साक्ष्य इसकी पहचान करता हो। ये अलग-अलग पंक्तियाँ हैं, "प्रेषक" के लिए विनिमेय लेबल नहीं। किसी संदेश को प्रमाणित करने वाला डोमेन उस व्यक्ति से भिन्न हो सकता है जिसके अधिकार का प्राप्तकर्ता ने अनुमान लगाया है।

RFC 9989 सीमा को स्पष्ट करता है: DMARC उपयोग डोमेन संरेखण और डोमेन के अलावा अन्य संस्थाओं को प्रमाणित नहीं करता या सामग्री का विश्लेषण नहीं करता। इसलिए एक सफल संरेखित परिणाम किसी चालान, नए बैंक विवरण या किसी कार्यकारी के अनुमोदन को प्रमाणित नहीं कर सकता है। इसके विपरीत, एक असफल परिणाम स्थापित नहीं होता है खाता अधिग्रहण. किसी जांच को एक प्रोटोकॉल परिणाम से इस निष्कर्ष पर पहुंचने से बचना चाहिए कि किसी व्यक्ति के खाते को कौन नियंत्रित करता है।

प्रत्येक अवलोकन के लिए विश्वास सीमा स्थापित करें

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

एप्लिकेशन लॉग और खाता ऑडिट रिकॉर्ड विभिन्न प्रश्नों के उत्तर देते हैं। एक भेजने वाला लॉग मानव इरादे को साबित किए बिना एक सफल सबमिशन दिखा सकता है। एक मेलबॉक्स ऑडिट यह साबित किए बिना कि नियम दुर्भावनापूर्ण था, नियम में बदलाव दिखा सकता है। जहां अधिकृत हो वहां समय, खाता और संदेश पहचानकर्ताओं द्वारा टिप्पणियों को संयोजित करें, लिंकेज कमजोर होने पर अनिश्चितता को बनाए रखें। किसी एक असामान्य स्थान या पृथक त्रुटि को समझौते का निर्णायक सबूत मानने से बचें।

नियंत्रण चुनने से पहले तंत्र की तुलना करें

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

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

परिचालन तुलना कार्यपत्रक

प्रति परिकल्पना एक पंक्ति बनाएँ। दावा की गई पहचान, सहायक अवलोकन, उस अवलोकन का स्रोत, परस्पर विरोधी साक्ष्य, प्रभावित नियंत्रण, प्रस्तावित अगली अधिकृत जांच और जिम्मेदार व्यक्ति शामिल करें। सरल भाषा में स्पष्टीकरण के साथ एक आत्मविश्वास लेबल जोड़ें। "विश्वसनीय रिसीवर रिपोर्ट आपूर्तिकर्ता डोमेन के लिए DKIM संरेखित करती है" "आपूर्तिकर्ता सुरक्षित होने की पुष्टि करता है" की तुलना में संकीर्ण और अधिक उपयोगी है। "प्राप्तकर्ता को प्रदर्शन नाम याद है" एक प्रमाणित आपूर्तिकर्ता पते के बराबर नहीं है।

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

काल्पनिक निदान: एक चालान-परिवर्तन अनुरोध

एक काल्पनिक निर्माता को आपूर्तिकर्ता के भुगतान गंतव्य को बदलने का अनुरोध प्राप्त होता है। प्रदर्शन नाम खाता प्रबंधक से मेल खाता है, और विश्वसनीय रिसीवर साक्ष्य आपूर्तिकर्ता के वास्तविक डोमेन के लिए संरेखित प्रमाणीकरण दिखाता है। प्राप्तकर्ता यह मानता है कि यह नियम BEC से बाहर है। इसके बजाय सुरक्षा टीम एक संक्षिप्त निष्कर्ष रिकॉर्ड करती है: संदेश ने एक प्रमाणित आपूर्तिकर्ता-डोमेन पथ का उपयोग किया। क्या आपूर्तिकर्ता खाता, एक एकीकरण या किसी अधिकृत व्यक्ति ने परिवर्तन शुरू किया यह अज्ञात है।

पहले से रिकॉर्ड किए गए आपूर्तिकर्ता संपर्क का उपयोग करके, व्यवसाय स्वामी विशिष्ट प्रस्तावित परिवर्तन को सत्यापित करेगा। एक अधिकृत आपूर्तिकर्ता उत्तरदाता अपने स्वयं के खाते और आवेदन साक्ष्य की जांच करेगा। यदि आपूर्तिकर्ता अनुरोध को अस्वीकार कर देता है, तो वह इनकार परिवर्तन को रोकने का समर्थन करता है लेकिन स्वयं यह पहचान नहीं करता है कि ईमेल कैसे भेजा गया था। मामला तब तक खुला रहता है जब तक खाता या सेवा साक्ष्य तंत्र का समाधान नहीं कर देता। यह पूरा उदाहरण काल्पनिक है; कोई भुगतान विवरण, आपूर्तिकर्ता खाता या वास्तविक पत्राचार प्राप्त नहीं किया गया।

प्रत्येक अनिश्चितता को सही साक्ष्य के साथ बंद करें

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

कैटलॉग को विश्वसनीय संदेश साक्ष्य से निर्मित एक संशोधित पहचान-और-नियंत्रण तुलना की आवश्यकता होती है। वह सबूत खुला रहता है. यह मसौदा एक विधि और काल्पनिक मामला प्रदान करता है, न कि विश्वसनीय मूल संदेश सामग्री। स्वतंत्र विशेषज्ञ समीक्षा, वर्तमान स्रोत प्रयोज्यता, उत्पादन मार्ग जांच, दृश्य पहुंच और मालिक की रिहाई भी खुली है। प्रकाशन को एक अधिकृत साक्ष्य पैकेज की प्रतीक्षा करनी चाहिए जो संवेदनशील खाता डेटा को उजागर किए बिना तुलना प्रदर्शित करता है या यह दर्शाता है कि गैर-निष्पादित प्रतिक्रिया कार्रवाई हुई है।