फीडर सिस्टम साइबरसुरक्षा गाइड: औद्योगिक फीडिंग उपकरण की सुरक्षा

एक कनेक्टेड फीडर एक अटैक सरफेस है

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

खतरा सैद्धांतिक नहीं है। 2023 में, जर्मनी में एक विनिर्माण संयंत्र ने रैंसमवेयर हमले के बाद 72 घंटे का उत्पादन खो दिया, जो IT नेटवर्क से एक साझा ईथरनेट स्विच के माध्यम से OT नेटवर्क में फैल गया, जिससे तीन असेंबली लाइनों पर PLC और फीडर कंट्रोलर अक्षम हो गए। फीडर खुद लक्ष्य नहीं थे — वे अपर्याप्त नेटवर्क सेगमेंटेशन के सहयोगी नुकसान थे। लेकिन प्रभाव वही था: लाइन रुक गई, और लागत लाखों यूरो में मापी गई।

यह गाइड औद्योगिक फीडिंग उपकरणों के लिए विशिष्ट साइबरसुरक्षा विचारों को कवर करता है: खतरे का परिदृश्य, नेटवर्क सेगमेंटेशन रणनीतियाँ, कंट्रोलर हार्डनिंग, IEC 62443 अनुपालन, और छोटे और मध्यम निर्माताओं के लिए व्यावहारिक कदम जिनके पास समर्पित OT सुरक्षा टीम नहीं हो सकती। यह हमारे PLC एकीकरण गाइड और हमारे फीडर HMI और अलार्म डिज़ाइन गाइड पर आधारित है, जो कनेक्टेड फीडर सिस्टम के कार्यात्मक पहलुओं को कवर करते हैं।

औद्योगिक फीडिंग उपकरणों के लिए खतरे का परिदृश्य

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

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

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

रिमोट एक्सेस शोषण। कई फीडर आपूर्तिकर्ता VPN, TeamViewer, या क्लाउड-आधारित डैशबोर्ड के माध्यम से रिमोट मॉनिटरिंग और समस्या निवारण प्रदान करते हैं। यदि ये रिमोट एक्सेस चैनल ठीक से सुरक्षित नहीं हैं (साझा क्रेडेंशियल, कोई MFA नहीं, हमेशा-चालू कनेक्शन), तो वे इंटरनेट से फीडर कंट्रोलर तक एक सीधा रास्ता प्रदान करते हैं।

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

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

नेटवर्क सेगमेंटेशन रणनीतियाँ

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

पर्ड्यू मॉडल, जो प्रक्रिया उद्योगों में व्यापक रूप से उपयोग किया जाता है, पदानुक्रमित नेटवर्क ज़ोन को परिभाषित करता है। फीडर सिस्टम वाले डिस्क्रीट मैन्युफैक्चरिंग के लिए, एक सरलीकृत तीन-ज़ोन मॉडल व्यावहारिक है:

महत्वपूर्ण नियम यह है: ज़ोन 3 (IT) और ज़ोन 1 (OT) के बीच कोई सीधा कनेक्शन नहीं। उनके बीच का सभी ट्रैफ़िक DMZ (ज़ोन 2) से गुज़रना चाहिए, जहाँ इसका निरीक्षण, लॉगिंग और नियंत्रण किया जा सकता है। ज़ोन 1 में एक फीडर कंट्रोलर इंटरनेट तक नहीं पहुँच सकता, और ज़ोन 3 में एक वर्कस्टेशन सीधे फीडर कंट्रोलर तक नहीं पहुँच सकता।

फ्लैट नेटवर्क वाले छोटे निर्माताओं के लिए (सब कुछ एक स्विच पर), पूर्ण पर्ड्यू मॉडल लागू करना अव्यावहारिक है। एक अधिक प्राप्य दृष्टिकोण VLAN अलगाव से शुरू करना है: सभी OT डिवाइस को एक अलग VLAN पर रखें जिसमें फ़ायरवॉल नियम हों जो IT VLAN से सभी इनबाउंड ट्रैफ़िक को ब्लॉक करें, सिवाय विशिष्ट, प्रलेखित अपवादों के (उदाहरण के लिए, historian सर्वर पोर्ट 502 पर Modbus TCP के लिए PLC डेटा पोल करना)।

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

कंट्रोलर हार्डनिंग

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

पासवर्ड नीतियाँ

कई फीडर कंट्रोलर पर डिफ़ॉल्ट पासवर्ड "admin," "1234," या खाली है। यह कमीशनिंग के दौरान बदलने वाली पहली चीज़ है, और यह सबसे अधिक छोड़ा गया कदम है। प्रत्येक कंट्रोलर में एक अद्वितीय, मजबूत पासवर्ड होना चाहिए (12+ अक्षर, मिश्रित केस, संख्याएँ, प्रतीक)। पासवर्ड को एक सुरक्षित पासवर्ड मैनेजर में दस्तावेज़ित करें — साझा ड्राइव पर स्प्रेडशीट में नहीं, और कंट्रोलर के किनारे चिपकाकर नहीं।

यदि कंट्रोलर कई उपयोगकर्ता खातों का समर्थन करता है, तो ऑपरेटरों (केवल-पढ़ने या सीमित नियंत्रण), इंजीनियरों (पूर्ण नियंत्रण), और व्यवस्थापकों (कॉन्फ़िगरेशन परिवर्तन) के लिए अलग खाते बनाएँ। यदि ऑपरेटर क्रेडेंशियल समझौता हो जाता है तो यह नुकसान की सीमा को सीमित करता है।

फर्मवेयर अपडेट

कंट्रोलर फर्मवेयर को कमीशनिंग के दौरान नवीनतम स्थिर संस्करण में अपडेट किया जाना चाहिए और फिर एक निर्धारित आधार पर (तिमाही या अर्ध-वार्षिक)। किसी भी अपडेट को लागू करने से पहले, निर्माता द्वारा प्रदान किए गए checksum या डिजिटल हस्ताक्षर का उपयोग करके फर्मवेयर अखंडता सत्यापित करें। यदि निर्माता कोड-साइन्ड फर्मवेयर प्रदान नहीं करता है, तो पूछें कि क्यों — और इसे अपने आपूर्तिकर्ता मूल्यांकन में एक जोखिम कारक मानें।

फर्मवेयर अपडेट को एक विश्वसनीय USB ड्राइव या OT नेटवर्क पर एक समर्पित इंजीनियरिंग वर्कस्टेशन से लागू किया जाना चाहिए, कभी भी ऐसे डिवाइस से नहीं जो इंटरनेट या IT नेटवर्क से भी कनेक्ट होता है। अपडेट प्रक्रिया को रखरखाव SOP में दस्तावेज़ित किया जाना चाहिए, जिसमें रोलबैक प्रक्रिया शामिल है यदि अपडेट समस्याएँ पैदा करता है।

पोर्ट और सेवा प्रबंधन

हर नेटवर्क सेवा को अक्षम करें जो फीडर के संचालन के लिए आवश्यक नहीं है। एम्बेडेड कंट्रोलर पर आम अनावश्यक सेवाओं में शामिल हैं: Telnet (पोर्ट 23), FTP (पोर्ट 21), HTTP एडमिन इंटरफेस (पोर्ट 80/443 यदि HMI के लिए उपयोग नहीं किया जाता), और UPnP। प्रत्येक खुला पोर्ट एक संभावित प्रवेश बिंदु है। यदि फीडर पोर्ट 502 पर Modbus TCP के माध्यम से PLC के साथ संवाद करता है, तो केवल पोर्ट 502 खुला होना चाहिए, और यह केवल PLC के IP address से सुलभ होना चाहिए।

यदि कंट्रोलर में वेब-आधारित प्रबंधन इंटरफेस है, तो फ़ायरवॉल नियमों के माध्यम से इंजीनियरिंग वर्कस्टेशन के IP address तक पहुँच को प्रतिबंधित करें। प्रबंधन इंटरफेस को पूरे OT VLAN के लिए उजागर न करें — केवल विशिष्ट डिवाइस जिन्हें इसकी आवश्यकता है।

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

फीडर सिस्टम के लिए IEC 62443 अवलोकन

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

मानक चार भागों में व्यवस्थित है:

• IEC 62443-1 (सामान्य): परिभाषाएँ, अवधारणाएँ, और समग्र सुरक्षा जीवनचक्र।
• IEC 62443-2 (एसेट स्वामी): जोखिम मूल्यांकन, सुरक्षा नीति, और ज़ोन/कंडुइट मॉडल — एसेट स्वामी की जिम्मेदारी।
• 62443-3 (सिस्टम): सिस्टम सुरक्षा आवश्यकताएँ और ज़ोन और कंडुइट के लिए सुरक्षा स्तर (SL) लक्ष्य।
• 62443-4 (घटक): व्यक्तिगत घटकों (कंट्रोलर, HMI, सेंसर) के लिए सुरक्षा आवश्यकताएँ — आपूर्तिकर्ता की जिम्मेदारी।

फीडर सिस्टम के लिए, सबसे प्रासंगिक भाग IEC 62443-4-2 है, जो घटकों के लिए Security Level 1 से 4 को परिभाषित करता है। अधिकांश फीडर कंट्रोलर SL 1 (आकस्मिक या अनजाने में उल्लंघन) या SL 2 (सरल साधन, कम संसाधन, कम प्रेरणा) को लक्षित करते हैं। SL 3 और SL 4 (परिष्कृत, जानबूझकर हमले) आमतौर पर केवल महत्वपूर्ण बुनियादी ढाँचे में आवश्यक होते हैं, डिस्क्रीट मैन्युफैक्चरिंग में नहीं।

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

रिमोट एक्सेस सुरक्षा

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

1. DMZ में एक समर्पित रिमोट एक्सेस गेटवे का उपयोग करें। इंटरनेट से OT नेटवर्क तक सीधे VPN कनेक्शन की अनुमति न दें। इसके बजाय, DMZ में एक रिमोट एक्सेस गेटवे (जैसे bastion host या व्यावसायिक OT रिमोट एक्सेस प्लेटफ़ॉर्म) रखें। गेटवे रिमोट उपयोगकर्ता प्रमाणित करता है, सत्र लॉग करता है, और OT डिवाइस से कनेक्शन प्रॉक्सी करता है।

2. बहु-कारक प्रमाणीकरण आवश्यक करें। प्रत्येक रिमोट एक्सेस सत्र के लिए MFA आवश्यक होना चाहिए — केवल पासवर्ड नहीं। हार्डवेयर टोकन, पंजीकृत मोबाइल डिवाइस पर पुश नोटिफिकेशन, या ऑथेंटिकेटर ऐप से वन-टाइम कोड सभी स्वीकार्य विधियाँ हैं। MFA के बिना साझा VPN क्रेडेंशियल एक महत्वपूर्ण कमज़ोरी हैं।

3. माँग पर कनेक्शन बनाएँ, हमेशा-चालू नहीं। VPN टनल या रिमोट एक्सेस सत्र केवल आवश्यक होने पर स्थापित किया जाना चाहिए और सत्र समाप्त होने पर डिस्कनेक्ट किया जाना चाहिए। आपूर्तिकर्ता के कार्यालय से आपके OT नेटवर्क तक हमेशा-चालू VPN कनेक्शन एक स्थायी अटैक सरफेस है जो किसी को लाभ नहीं देता जब कोई सक्रिय समस्या निवारण सत्र नहीं है।

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

छोटे और मध्यम निर्माताओं के लिए व्यावहारिक कदम

हर निर्माता के पास समर्पित OT सुरक्षा टीम, SIEM प्लेटफ़ॉर्म, या पूर्ण पर्ड्यू मॉडल नेटवर्क आर्किटेक्चर नहीं है। सीमित संसाधनों वाले संयंत्रों के लिए, निम्नलिखित कदम सबसे कम निवेश पर सबसे अधिक सुरक्षा प्रतिफल प्रदान करते हैं:

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

कदम 2: सभी डिफ़ॉल्ट पासवर्ड बदलें। यह सबसे अधिक प्रभाव वाला कार्य है। आज करें। प्रत्येक कंट्रोलर के लिए अद्वितीय पासवर्ड का उपयोग करें, पासवर्ड मैनेजर में संग्रहीत।

कदम 3: OT डिवाइस को अलग VLAN पर रखें। अधिकांश मैनेज्ड स्विच VLAN का समर्थन करते हैं। IT डिवाइस के लिए एक VLAN और OT डिवाइस के लिए एक VLAN बनाएँ। एक सरल फ़ायरवॉल नियम जोड़ें: OT VLAN इंटरनेट तक नहीं पहुँच सकता; IT VLAN, OT VLAN तक प्रलेखित अपवादों के माध्यम से ही पहुँच सकता है।

कदम 4: प्रत्येक कंट्रोलर पर अनावश्यक सेवाएँ अक्षम करें। Telnet, FTP, HTTP एडमिन इंटरफेस — यदि आप उनका उपयोग नहीं कर रहे हैं, तो उन्हें बंद कर दें। यह प्रति कंट्रोलर 10 मिनट लेता है।

कदम 5: रिमोट एक्सेस को सुरक्षित करें। साझा VPN क्रेडेंशियल को व्यक्तिगत खातों और MFA से बदलें। यदि आपका वर्तमान रिमोट एक्सेस सेटअप MFA का समर्थन नहीं करता है, तो ऐसे प्लेटफ़ॉर्म पर स्विच करें जो करता है। एक व्यावसायिक OT रिमोट एक्सेस समाधान की लागत ($2,000-5,000/वर्ष) एकल रैंसमवेयर घटना की लागत की तुलना में नगण्य है।

कदम 6: फर्मवेयर अपडेट शेड्यूल करें। तिमाही आधार पर कंट्रोलर फर्मवेयर अपडेट की जाँच करें। विश्वसनीय इंजीनियरिंग वर्कस्टेशन से लागू करें, checksum सत्यापित करें, और रखरखाव लॉग में अपडेट दस्तावेज़ित करें।

• पहले इन्वेंट्री: आप उन डिवाइस को सुरक्षित नहीं कर सकते जिन्हें आप नहीं जानते।
• डिफ़ॉल्ट पासवर्ड सबसे आसान लक्ष्य हैं: कुछ और करने से पहले उन्हें बदलें।
• VLAN अलगाव सबसे अधिक ROI वाला नेटवर्क परिवर्तन है: यह 5% प्रयास से 80% क्षैतिज गतिविधि को रोकता है।
• रिमोट एक्सेस MFA अनिवार्य है: साझा VPN क्रेडेंशियल एक महत्वपूर्ण कमज़ोरी हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या नेटवर्क कनेक्शन के बिना स्टैंडअलोन फीडर जोखिम में हैं?

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

क्या करें यदि फीडर आपूर्तिकर्ता समर्थन के लिए रिमोट एक्सेस पर ज़ोर देता है?

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

क्या IEC 62443 फीडर सिस्टम पर लागू होता है?

IEC 62443 किसी भी औद्योगिक स्वचालन और नियंत्रण प्रणाली पर लागू होता है, फीडर सिस्टम सहित, यदि एसेट स्वामी की सुरक्षा नीति इसकी आवश्यकता करती है। व्यवहार में, डिस्क्रीट मैन्युफैक्चरिंग में अधिकांश फीडर सिस्टम प्लांट-वाइड IEC 62443 अनुपालन कार्यक्रम के तहत आते हैं बजाय व्यक्तिगत रूप से प्रमाणित होने के। फीडर आपूर्तिकर्ता की जिम्मेदारी ऐसे घटक प्रदान करना है जो एसेट स्वामी द्वारा परिभाषित सुरक्षा आवश्यकताओं को पूरा करते हैं — आमतौर पर IEC 62443-4-2 के तहत SL 1 या SL 2। यदि आपका संयंत्र IEC 62443 अनुपालन का पीछा कर रहा है, तो फीडर RFQ में लागू सुरक्षा स्तर शामिल करें।

मैं उन लेगसी फीडर को कैसे सुरक्षित करूँ जिन्हें अपडेट नहीं किया जा सकता?

पुराने फर्मवेयर, बिना पासवर्ड सुरक्षा, और बिना नेटवर्क सेगमेंटेशन क्षमताओं वाले लेगसी फीडर को नेटवर्क स्तर पर अलग किया जाना चाहिए। उन्हें एक समर्पित VLAN पर रखें जिसमें किसी अन्य नेटवर्क ज़ोन से कोई कनेक्शन न हो। यदि उन्हें PLC के साथ संवाद करना है, तो एक प्रोटोकॉल कनवर्टर या फ़ायरवॉल का उपयोग करें जो केवल आवश्यक विशिष्ट Modbus या डिजिटल I/O ट्रैफ़िक की अनुमति देता है, बाकी सब ब्लॉक करता है। यदि लेगसी कंट्रोलर में वेब इंटरफेस या Telnet है, तो इसे अक्षम करें या फ़ायरवॉल पर एक्सेस ब्लॉक करें। लक्ष्य लेगसी फीडर को ऐसे नेटवर्क से अपहरणीय बनाना है जिसे हमलावर समझौता कर सकता है।

साइबरसुरक्षा के लिए RFQ में मुझे क्या शामिल करना चाहिए?

RFQ में निम्नलिखित निर्दिष्ट करें: नेटवर्क कनेक्टिविटी आवश्यकताएँ (कौन से प्रोटोकॉल, कौन से पोर्ट), पासवर्ड प्रबंधन क्षमताएँ (अद्वितीय खाते, पासवर्ड जटिलता, खाता लॉकआउट), फर्मवेयर अपडेट प्रक्रिया (कोड साइनिंग, checksum सत्यापन, रोलबैक क्षमता), रिमोट एक्सेस आवश्यकताएँ (आपका बुनियादी ढाँचा, MFA, सत्र लॉगिंग), और IEC 62443 अनुपालन स्तर यदि लागू हो। आपूर्तिकर्ता से कंट्रोलर के लिए एक सुरक्षा डेटाशीट या SBOM (Software Bill of Materials) प्रदान करने की भी आवश्यकता करें, जिसमें सभी सॉफ़्टवेयर घटकों और ज्ञात कमज़ोरियों की सूची हो। यह OT खरीद में मानक अभ्यास बनता जा रहा है।

निष्कर्ष

फीडर सिस्टम के लिए साइबरसुरक्षा फीडर की सुरक्षा के बारे में नहीं है — यह फीडर को व्यापक OT नेटवर्क पर हमलों के वेक्टर बनने से रोकने के बारे में है। सबसे महत्वपूर्ण उपाय हैं नेटवर्क सेगमेंटेशन (IT को OT से अलग करना), कंट्रोलर हार्डनिंग (डिफ़ॉल्ट पासवर्ड बदलना, अनावश्यक पोर्ट बंद करना, फर्मवेयर अपडेट करना), और सुरक्षित रिमोट एक्सेस (MFA, माँग पर कनेक्शन, सत्र लॉगिंग)। ये कदम महँगे या तकनीकी रूप से जटिल नहीं हैं, लेकिन इन्हें अनुशासन और निरंतरता की आवश्यकता है। इन्वेंट्री और डिफ़ॉल्ट पासवर्ड परिवर्तनों से शुरू करें — इनमें घंटे लगते हैं, हफ़्ते नहीं — और वहाँ से आगे बढ़ें। यदि आपको नए फीडर इंस्टॉलेशन के लिए साइबरसुरक्षा आवश्यकताएँ निर्दिष्ट करने या अपने मौजूदा फीडिंग उपकरण की सुरक्षा स्थिति का मूल्यांकन करने में मदद चाहिए, हमसे संपर्क करें।