नया: Antivirus AI Mac अब उपलब्ध हैअभी देखो →
हिन्दी
Deutsch English Español Français Italiano Português Русский العربية 日本語 简体中文
तुम्हारे लिए
तुम्हारी निजता.
बिना समझौते.
Android, iPhone, Mac और Windows के लिए रियल-टाइम AI सुरक्षा। स्वतंत्र रूप से प्रमाणित और कई बार पुरस्कृत।
उत्पाद देखो
AndroidAndroid
Anti Spy newfree
स्पायवेयर पहचानो और ब्लॉक करो
Antivirus AI newfree
रियल-टाइम AI सुरक्षा
Firewall AI free
नेटवर्क एक्सेस नियंत्रित करो
Camera Guard free
कैमरा रियल-टाइम में मॉनिटर करो
Micro Guard free
माइक्रोफ़ोन को जासूसी से बचाओ
iShredder newfree
डेटा हमेशा के लिए मिटाओ
iOSiOS
iShredder iOS new
फ़ोटो और फ़ाइलें सुरक्षित रूप से मिटाओ
MacMac
Antivirus AI Mac free
macOS के लिए वायरस सुरक्षा
Camera Guard Mac
कैमरा रियल-टाइम में मॉनिटर करो
iShredder Mac
प्रमाणित फ़ाइल डिलीशन
iShredder iOS
Apple Silicon Mac पर भी चलता है
iLocker Mac
ऐप्स को एन्क्रिप्ट और लॉक करो
WindowsWindows
iShredder Windows
प्रमाणित डेटा इरेज़र
iShredder Server
सर्वर और IT टीमों के लिए
iShredder Technical
23 प्रमाणित इरेज़र मानक
बिज़नेस के लिए
तुम्हारे संगठन की
सुरक्षा.
SMB, सरकारी एजेंसियों और एंटरप्राइज़ के लिए प्रमाणित डेटा इरेज़र और सुरक्षा — पूरी तरह GDPR-अनुरूप।
बिज़नेस समाधान देखो
Android & iOS
iShredder Business b2b
कई डिवाइस सुरक्षित रूप से वाइप करो
iShredder Enterprise
MDM इंटीग्रेशन और सर्टिफिकेट
Windows Server
iShredder Server b2b
सर्वर और RAID एरे वाइप करो
iShredder Technical
बूटेबल, 23 प्रमाणित इरेज़र मानक
डिफेंस के लिए
डिफेंस समाधान
डिफेंस समाधान gov
दुनिया भर की सरकारी एजेंसियाँ और रक्षा संगठन हम पर भरोसा करते हैं
हमारे बारे में
सुरक्षा को आकार दे रहे हैं
2004 से.
हम दुनिया भर में 8 मिलियन से ज़्यादा लोगों की निजता की रक्षा करते हैं — स्वतंत्र रूप से, पारदर्शिता के साथ और बिना अनावश्यक डेटा संग्रह के।
हमारी कहानी
कंपनी
Protectstar
हम कौन हैं और हमें क्या प्रेरित करता है
हमारा दर्शन
सुरक्षा एक मानव अधिकार है
Protectstar क्यों
प्रमाणित और पुरस्कृत
तुम्हारी निजता
हम तुम्हारे डेटा की रक्षा कैसे करते हैं
पर्यावरण
धरती के लिए हमारी प्रतिबद्धता
टीम और प्रेस
हमारी टीम
Protectstar के पीछे की टीम
संस्थापक का संदेश
विज़न और मिशन, सीधे संस्थापक से
प्रेस सेंटर
मीडिया, लोगो और प्रेस किट
टेक्नोलॉजी
आर्टिफ़िशियल इंटेलिजेंस
आर्टिफ़िशियल इंटेलिजेंस
ऑन-डिवाइस AI रियल-टाइम में नई धमकियाँ पहचानता है
iShredding
iShredding
23 प्रमाणित इरेज़र मानक
तुम्हारे लिए
बिज़नेस के लिए
हमारे बारे में
FAQ और सपोर्टब्लॉग

फ़्रीज़र डिस्प्ले केस में 50 °C: वह रात, जब रेफ्रिजरेशन सिस्टम हीटर बन गए

फ़्रीज़र डिस्प्ले केस में 50 °C: वह रात, जब रेफ्रिजरेशन सिस्टम हीटर बन गए
November 03, 2026

रेफ्रिजरेशन सिस्टम पर हो रहे हमले यूरोप के सुपरमार्केटों को खाद्य पदार्थ फेंकने के लिए मजबूर कर रहे हैं। ये घटनाएँ एक चिंताजनक संभावना सामने लाती हैं: उपकरणों के सामान्य संचालन के लिए बने फ़ंक्शन भी नुकसान पहुँचा सकते हैं। इसलिए अहम सवाल केवल यह नहीं है कि हमलावर अंदर कैसे आते हैं, बल्कि यह भी है कि उनके अंदर आ जाने के बाद उन्हें क्या रोक सकता है।

पहला संकेत है फ़र्श पर जमा पानी।
सोमवार, 2 नवंबर 2026 की सुबह, Mats Olsson स्वीडन के Öland द्वीप पर Böda में स्थित अपने ICA स्टोर में प्रवेश करते हैं और फ़र्श पर पानी पाते हैं। वे स्वीडिश प्रसारक SVT को बताते हैं कि उनके फ़्रीज़र सिस्टम का तापमान 55 °C तक पहुँच गया था और शीतलित और जमे हुए खाद्य पदार्थों का स्टॉक खराब हो चुका था। स्टोर खुला रहता है, लेकिन वही उत्पाद गायब हैं जिन्हें ठंडा रखने के लिए उसके उपकरण लगाए गए थे।

स्टॉकहोम में भी घटना आधी रात के बाद शुरू होती है। बिक्री प्रबंधक Engla Ingwall के अनुसार, उनके ICA स्टोर के फ़्रीज़र सिस्टम पर हमला लगभग रात दो बजे शुरू होता है। कई घंटों तक किसी को इसका पता नहीं चलता। Reuters से बातचीत में वे 50 °C तापमान और खराब हुए स्टॉक की जानकारी देती हैं। जब तक डिजिटल छेड़छाड़ सामने आती है, भौतिक प्रक्रियाएँ नुकसान कर चुकी होती हैं।

2 नवंबर को दिन भर बेल्जियम, लक्ज़मबर्ग और एस्टोनिया से भी ऐसी ही खबरें आती हैं। नीदरलैंड्स में Danfoss, NOS को पुष्टि करती है कि कम-से-कम 17 कारोबार प्रभावित हुए हैं, जिनमें छोटे किराना स्टोर और फ़्रोज़न खाद्य पदार्थों का एक गोदाम शामिल है। तीन सप्ताह पहले इसी तरह के एक हमले ने फ़्रांस के सैकड़ों स्टोरों को प्रभावित किया था। यह लेख लिखे जाने तक सार्वजनिक जानकारी से स्पष्ट नहीं था कि इन घटनाओं के पीछे वही हमलावर थे या नहीं।

लेकिन सामने उठने वाले सवाल का जवाब हमलावरों की पहचान पर निर्भर नहीं है: ठंडा करने के लिए बनाया गया सिस्टम गर्मी का स्रोत कैसे बन जाता है? इसका जवाब एक ऐसे फ़ंक्शन में है जो उसके सामान्य संचालन के लिए बनाया गया है।

मशीन वही करती है जो उसे कहा जाता है। बस निर्देश देने वाला गलत व्यक्ति होता है।

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

अहम हैं अवधि, संचालन का क्रम और उस पर लागू सीमाएँ। बेल्जियम की घटनाओं में रेफ्रिजरेशन सेवा प्रदाता Sabcobel ने बताया कि इवैपोरेटरों को दूर से डीफ़्रॉस्ट मोड में डाल दिया गया था। हमलावरों को मशीन का कोई नया फ़ंक्शन बनाने की जरूरत नहीं पड़ी। उन्होंने मौजूदा फ़ंक्शन को ही सिस्टम के उद्देश्य के विरुद्ध इस्तेमाल किया।

रेफ्रिजरेटेड डिस्प्ले केस के पीछे अक्सर नियंत्रण की पूरी पदानुक्रमित व्यवस्था होती है। स्थानीय कंट्रोलर सेंसरों और वाल्वों के साथ काम करते हैं; उनसे ऊपर का सिस्टम मैनेजर जानकारी एकत्र करता है और दूरस्थ प्रशासन की सुविधा देता है। Claroty द्वारा जाँचे गए Danfoss AK-SM 800A में एक अंतर्निहित वेब इंटरफ़ेस है, जिससे तापमान की सीमाएँ, समय-सारिणियाँ, अलार्म और उपयोगकर्ता खाते समेत कई चीजें प्रबंधित की जा सकती हैं। इससे तकनीशियन को मौके पर जाने की जरूरत नहीं पड़ती, लेकिन आवश्यक पहुँच रखने वाले व्यक्ति को काफी नियंत्रण भी मिल जाता है।

ऐसे सिस्टम ऑपरेशनल टेक्नोलॉजी, यानी OT, का हिस्सा हैं: ऐसी तकनीक जो भौतिक प्रक्रियाओं की निगरानी करती है या उन पर असर डालती है। यहाँ कोई कमांड केवल डेटा रिकॉर्ड नहीं बदलता। वह यह तय कर सकता है कि वाल्व, मोटर या हीटर आगे क्या करेगा।

किसी प्रक्रिया में दुर्भावनापूर्ण बदलाव करने के लिए ऑपरेटिंग सिस्टम पर कब्ज़ा करना हमेशा जरूरी नहीं है। पर्याप्त विशेषाधिकार वाला ऑपरेटर एक्सेस ही काफी हो सकता है। औद्योगिक नियंत्रण प्रणालियों के लिए अपने ATT&CK फ्रेमवर्क में MITRE इस हमले के तरीके को “Modify Parameter” (T0836) कहता है: बदले हुए संचालन पैरामीटर सामान्य रूप से ठीक काम कर रहे कंट्रोलर से अवांछित संचालन-क्रम चलवाते हैं। केवल इससे यह पता नहीं चलता कि इन घटनाओं में मैलवेयर भी इस्तेमाल हुआ था या नहीं।

यह अंतर महत्वपूर्ण है। केवल दुर्भावनापूर्ण फ़ाइलें खोजने पर, सिस्टम के नियंत्रणों के जरिए की गई दुर्भावनापूर्ण कार्रवाई नज़र से छूट सकती है। कमांड औपचारिक रूप से वैध हो सकता है, सॉफ़्टवेयर उसे सही ढंग से संसाधित कर सकता है, और फिर भी उपकरण गलत काम कर सकता है। हरा स्टेटस इंडिकेटर केवल उसी चीज की जानकारी देता है जिसकी वह वास्तव में निगरानी करता है। “सिस्टम चल रहा है” और “प्रक्रिया नियंत्रण में है” एक ही बात नहीं हैं।

तापमान के चौंकाने वाले आँकड़ों में भी यही सटीकता जरूरी है। तापमान के निर्धारित मान (सेटपॉइंट), इवैपोरेटर का तापमान, हवा का तापमान और उत्पादों का तापमान अलग-अलग चीजें हैं। तापमान की सेटिंग को 50 °C करना इस बात का प्रमाण नहीं है कि खाद्य पदार्थ स्वयं उस तापमान तक पहुँच गए। एस्टोनिया का एक प्रभावित स्टोर इसका उदाहरण है: सेटिंग 50 °C होने के बावजूद, वास्तविक तापमान में बताई गई वृद्धि मामूली रही। वहाँ निर्णायक बात प्रतिक्रिया की गति थी।

कॉर्पोरेट आईटी सुरक्षा को दरकिनार करने वाला दूसरा प्रवेश मार्ग

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

कोई सिस्टम बिक्री काउंटरों के नेटवर्क से अलग हो सकता है और फिर भी बाहरी दुनिया से उसका कोई असुरक्षित कनेक्शन हो सकता है। ब्रिटेन का NCSC स्पष्ट रूप से उन अतिरिक्त संचार मार्गों के बारे में चेतावनी देता है जिन्हें सेवा प्रदाता स्थापित कर सकते हैं, जैसे उनके अपने मोबाइल नेटवर्क कनेक्शन। केवल कंपनी के ज्ञात कनेक्शन जाँचने पर ये प्रवेश मार्ग नज़र से छूट सकते हैं। महत्वपूर्ण चीज कंट्रोलर तक वास्तविक कनेक्शन है, न कि यह सीमा कि एक टीम की जिम्मेदारी कहाँ खत्म होती है और दूसरी की कहाँ शुरू।

Claroty की Team82 ने एक खोज के जरिए इस अटैक सरफ़ेस के संभावित आकार को दिखाया। उस खोज में जाँचे गए प्लेटफ़ॉर्म के 2,765 ऐसे उपकरण मिले जो सार्वजनिक रूप से पहुँच योग्य थे। यह उस समय इंटरनेट से उनकी पहुँच-योग्यता की झलक थी, हैक किए गए सुपरमार्केटों की सूची नहीं। लेकिन यह उस आश्वस्त करने वाली धारणा को गलत साबित करता है कि ऐसे प्रबंधन इंटरफ़ेस हमेशा बंद कॉर्पोरेट नेटवर्कों के भीतर छिपे होते हैं।

नीदरलैंड्स के बारे में अब तक की रिपोर्टिंग किसी अज्ञात हाई-टेक हमले से अधिक अपर्याप्त सुरक्षा उपायों की ओर संकेत करती है। Danfoss के एक प्रवक्ता ने NOS को बताया कि प्रभावित सिस्टम डिफ़ॉल्ट पासवर्ड इस्तेमाल कर रहे थे और सुरक्षित नेटवर्क के जरिए जुड़े नहीं थे। प्रवक्ता के अनुसार, फ़्रांस की घटना के बाद निर्माता पहले ही उपकरणों तक इंटरनेट से सीधे पहुँच बंद करने की सलाह दे चुका था। यह निर्माता का विवरण है, प्रत्येक मामले का स्वतंत्र पुनर्निर्माण नहीं।

उत्पादों में ऐसी सुरक्षा कमजोरियाँ भी हैं जिनका विवरण प्रकाशित किया जा चुका है। AK-SM-8xxA सीरीज़ के लिए Danfoss, CVE-2025-41450 को 4.2 से पुराने संस्करणों को प्रभावित करने वाली प्रमाणीकरण समस्या के रूप में सूचीबद्ध करती है। 4.3.1 से पुराने संस्करणों में CVE-2025-41451 ऑपरेटिंग सिस्टम स्तर पर कमांड चलाए जाने की संभावना बताती है, जबकि CVE-2025-41452 वेब सर्वर की ऐसी कॉन्फ़िगरेशन से संबंधित है जिसमें छेड़छाड़ करके सेवा बाधित की जा सकती है (डिनायल ऑफ़ सर्विस)। अंतिम दो कमजोरियों के लिए सफल प्रमाणीकरण आवश्यक है।

Team82 ने “Code of the Day” नाम के एक वैकल्पिक लॉगिन तंत्र का भी वर्णन किया, जो सामान्य लॉगिन प्रक्रिया को दरकिनार कर सकता था। मूल समस्या यह है कि एक मजबूत एडमिनिस्ट्रेटर पासवर्ड, अतिरिक्त एक्सेस तंत्र की हर खामी से सुरक्षा नहीं देता।

जाँचे गए सार्वजनिक स्रोतों से यह तय नहीं होता कि वर्तमान हमलों में इनमें से कौन-सी कमजोरी इस्तेमाल हुई, या इनमें से कोई इस्तेमाल हुई भी या नहीं। अलग-अलग उत्पाद परिवारों को भी एक नहीं मानना चाहिए: CERT-FR ने Danfoss AK-SM और AK-SC सिस्टमों के साथ Copeland और Dixell के XWEB सिस्टमों का उल्लेख किया है। इसलिए एक अकेली CVE सभी घटनाओं की व्याख्या नहीं करती।

एक और समस्या है जो बिक्री कक्ष में नज़र नहीं आती: उपकरणों का पुराना पड़ना। निर्माता के अनुसार, पुराने Danfoss AK-SM 800 का उत्पाद जीवनचक्र मई 2021 में समाप्त हो गया था। अक्टूबर 2025 में Danfoss ने फिर स्पष्ट किया कि संबंधित पुराने उत्पादों का समर्थन खत्म हो चुका है। यह सिस्टम मैनेजर नए 800A प्लेटफ़ॉर्म के समान नहीं है। नए प्लेटफ़ॉर्म के अपडेट सभी पुराने उपकरणों पर सीधे लागू नहीं किए जा सकते।

डिजिटल कंट्रोलर का समर्थन समाप्त हो जाने के बाद भी उपकरण यांत्रिक रूप से काम करता रह सकता है। तब “यह अब भी ठंडा रखता है” उसकी मौजूदा कार्यक्षमता बताता है, उसके रखरखाव एक्सेस की सुरक्षा नहीं।

हमलावर पहले ही लॉगिन कर चुका हो, तो उसे क्या रोक सकता है?

पहली सुरक्षा पंक्ति प्रबंधन इंटरफ़ेस तक पहुँच को सुरक्षित करे: वह सीधे इंटरनेट से उपलब्ध न हो, दूरस्थ एक्सेस सुरक्षित हो, हर उपयोगकर्ता का अलग खाता हो और जहाँ संभव हो, फ़िशिंग-प्रतिरोधी बहु-कारक प्रमाणीकरण लागू हो। CERT-FR और NCSC यही तरीका सुझाते हैं। इससे शुरुआती प्रवेश कठिन होता है। लेकिन हमलों के बावजूद टिक सकने वाले आर्किटेक्चर को इसके बाद दूसरे सवाल का जवाब देना चाहिए: हमलावर किसी सेंध लगे एक्सेस मार्ग से वास्तव में क्या कर सकता है?

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

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

ये सीमाएँ केवल सैद्धांतिक विचार नहीं हैं। उदाहरण के लिए, Danfoss AK-CC 750 कंट्रोलर के दस्तावेज़ में डीफ़्रॉस्ट चक्र समाप्त करने की तापमान और समय पर आधारित शर्तें दी गई हैं। इससे यह साबित नहीं होता कि प्रभावित स्टोरों में यही कंट्रोलर इस्तेमाल हो रहा था। लेकिन यह दिखाता है कि तकनीकी समीक्षा को क्या पूछना चाहिए: कौन-सी सीमाएँ मौजूद हैं, वे कहाँ लागू होती हैं और उन्हें कौन बदल सकता है?

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

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

और गहरा सवाल यह है कि सुरक्षा फ़ंक्शन वास्तव में स्वतंत्र हैं या नहीं। यदि एक ही प्रशासनिक एक्सेस प्रक्रिया बदल भी सकता है और उसकी सीमाएँ हटा भी सकता है, तो ये फ़ंक्शन स्वतंत्र सुरक्षा परतें नहीं हैं। यदि वह अलार्म का व्यवहार भी बदल सकता है, तो हमलावर उसी एक्सेस के जरिए हमले का पता चलने में देरी भी कर सकता है। NIST, OT सिस्टमों में नियंत्रण और सुरक्षा फ़ंक्शन के बीच अपर्याप्त पृथक्करण के बारे में स्पष्ट चेतावनी देता है।

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

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

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

वे मिनट, जिनमें नुकसान अभी भी रोका जा सकता है

एस्टोनिया में उस रात का अंत अलग हुआ। हमलावरों ने एक पुराने सिस्टम के नियंत्रण कंप्यूटर तक पहुँच बनाई और Selver का एक स्टोर प्रभावित हुआ। सेवा प्रदाता ने लगभग दस मिनट के भीतर प्रतिक्रिया देने की बात कही। उसके विवरण के अनुसार, वास्तविक तापमान केवल 2 से 3 °C बढ़ा और किसी खाद्य पदार्थ को नुकसान नहीं हुआ। Selver ने बताया कि यह आखिरी स्थान था जहाँ नया सिस्टम अभी लगाया नहीं गया था।

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

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

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

लॉग ऐसे होने चाहिए कि यह तुलना की जा सके। उपयोगी रिकॉर्ड से इस्तेमाल किए गए खाते, प्रभावित उपकरण, बदलाव और उसके समय की पहचान होनी चाहिए। जहाँ उपलब्ध हों, पिछला मान और संबंधित रखरखाव कार्यादेश भी उस बदलाव से जुड़े होने चाहिए। यह NCSC के जोर दिए गए सिद्धांत को दर्शाता है: लॉगिंग का उद्देश्य खतरे का पता लगाने के विशिष्ट लक्ष्यों को पूरा करने में मदद करना होना चाहिए, केवल डेटा जमा करना नहीं। जिन लॉगों को नुकसान होने के बाद ही देखा जाए, वे समय रहते चेतावनी नहीं दे सकते।

इसके बाद कोई ऐसा व्यक्ति होना चाहिए जो उस क्रम को रोक सके। NCSC पृथक्करण की जाँची-परखी योजनाओं की सलाह देता है: कौन-सा कनेक्शन बंद किया जा सकता है? कौन-से फ़ंक्शन स्थानीय रूप से चलते रहने चाहिए? दूरस्थ रखरखाव उपलब्ध न होने पर सेवा प्रदाता कैसे जिम्मेदारी संभालेगा? सही प्रतिक्रिया जरूरी नहीं कि पूरे सिस्टम की बिजली काट देना हो। उसे लोगों की सुरक्षा करनी चाहिए और प्रक्रिया को पहले से तय, नियंत्रित की जा सकने वाली स्थिति में लाना चाहिए।

योजना में यह भी तय होना चाहिए कि अलग करने के बाद सिस्टम की स्थिति पर कितनी निगरानी बनी रहेगी। यदि दूरस्थ रखरखाव डिस्कनेक्ट करते समय गलती से एकमात्र अलार्म चैनल भी कट जाए, तो ऑन-कॉल टीम वही फीडबैक खो देती है जिसकी उसे जरूरत है। परीक्षण केवल यह नहीं है कि एक्सेस बंद किया जा सकता है या नहीं। यह भी जाँचना है कि जिम्मेदार लोग बाद में भी पता लगा सकें कि उनका बचाव उपाय काम कर रहा है या नहीं।

यहाँ एक अंतर आसानी से छूट सकता है: नेटवर्क से अलग करना पहले से बदली हुई सेटिंग को अपने-आप वापस नहीं करता। इससे आगे की पहुँच बंद हो सकती है, जबकि उपकरण छेड़छाड़ करके बदली गई सेटिंग के अनुसार चलता रहता है। इसलिए विशेषज्ञों को केवल एक्सेस मार्ग ही नहीं, वास्तविक संचालन स्थिति और कॉन्फ़िगरेशन भी जाँचनी चाहिए। “अब नेटवर्क से पहुँच नहीं है” उतना ही अपर्याप्त सुरक्षा आश्वासन है जितना “फिर से चल रहा है”।

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

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

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

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

Öland में फ़र्श पर जमा पानी ने घटना को उजागर किया। एस्टोनिया में संचालक ने बताया कि खाद्य पदार्थों को नुकसान नहीं हुआ। इन दो परिणामों के बीच ही सुरक्षा की असली चुनौती है: नुकसान के जरिए हमला सामने आने से पहले उसे पहचानना और हमलावर को पहुँच मिल जाने के बाद भी प्रभावी सुरक्षा उपाय बनाए रखना।

बैकअप कॉन्फ़िगरेशन वापस ला सकता है। वह पर्याप्त शीतलन के बिना बीते घंटों को वापस नहीं ला सकता।

साइबर हमले में मशीन को नष्ट करना जरूरी नहीं है। कभी-कभी उससे गलत काम करवाना ही काफी होता है।

क्या यह लेख सहायक था? हाँ नहीं
1 में से 1 लोगों ने इस लेख को सहायक पाया
रद्द करें जमा करें
Back वापस जाएं