सब कुछ जो जानना ज़रूरी है, कुछ भी नहीं जो ज़रूरी नहीं है।
हमलावर कैसे स्पूफ करते हैं
तीन पैटर्न। वे एक कमज़ोर-गवर्नेंस वाले एग्रीगेटर के माध्यम से सबमिट करते हैं जो पंजीकृत मालिकों के लिए सेंडर ID व्हाइटलिस्टिंग लागू नहीं करता है (ऐसा कभी नहीं होना चाहिए, लेकिन होता है)। वे एक विदेशी SS7 पाथ के माध्यम से रूट करते हैं जो स्थानीय सेंडर ID जांच को बायपास कर देता है (ज़्यादातर FS.07-अलाइन वाले फ़ायरवॉल द्वारा बंद कर दिया जाता है)। वे एक वास्तविक MSISDN से भेजने के लिए SIM-बॉक्स इंफ्रास्ट्रक्चर का दुरुपयोग करते हैं, जिसे वे बाद में एक नकली ब्रांड स्ट्रिंग के साथ अल्फ़ान्यूमेरिक-ओवरले कर देते हैं (कुछ एग्रीगेटर स्टैक इसकी अनुमति देते हैं)।
ऑपरेटर कैसे बचाव करते हैं
सेंडर ID रजिस्ट्रेशन (बुनियादी सुरक्षा)। एग्रीगेटर पर आउटबाउंड सेंडर ID प्रवर्तन: BroadNet का सबमिशन गेटवे किसी भी submit_sm को अस्वीकार कर देता है जिसका अल्फ़ान्यूमेरिक sender field गंतव्य देश के लिए ग्राहक के स्वीकृत सेंडर ID व्हाइटलिस्ट में नहीं है। ऑपरेटर फ़ायरवॉल पर इनबाउंड सेंडर ID वैलिडेशन: देश के अनुसार पंजीकृत मालिक के विरुद्ध आने वाले A2P ट्रैफिक के क्लेम किए गए सेंडर की क्रॉस-चेक की जाती है।
खरीदारों को अपने एग्रीगेटर से क्या उम्मीद करनी चाहिए
सख्त व्हाइटलिस्टिंग। यदि आपका एग्रीगेटर आपको पूर्व अनुमोदन के बिना API-कॉल समय पर सेंडर ID को किसी भी मनमाने स्ट्रिंग पर सेट करने की अनुमति देता है, तो वह एग्रीगेटर पूरे इकोसिस्टम के लिए स्मिशिंग (smishing) का जोखिम है। प्रतिष्ठित एग्रीगेटर सेंडर-ID के प्री-रजिस्ट्रेशन की मांग करते हैं। बस इतना ही।
रेगुलेटरी स्थिति
MENA रेगुलेटर्स (TDRA, CST, NTRA, TRC) सेंडर-ID स्पूफिंग पर तेजी से सख्त हो रहे हैं। EU मार्केट्स में ऑपरेटर्स EU NIS2 फ्रेमवर्क के तहत SMS-Sender-ID वैलिडेशन तैनात कर रहे हैं। RCS Business Messaging धीरे-धीरे ट्रस्ट-क्रिटिकल SMS की जगह ले रहा है क्योंकि सेंडर को क्रिप्टोग्राफिक रूप से सत्यापित किया जाता है।