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

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

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

दूसरा, जब किसी वेंडर को खास तौर पर गलत हमलों को रोकने का काम सौंपा जाता है, तब भी उस वेंडर की अपनी मज़बूती को मिशन-क्रिटिकल माना जाना चाहिए। यह मानना कि साइबर-डिफेंडर फेल होने से परे है, अब सही नहीं है। तीसरा, सिस्टमिक रिस्क इंफ्रास्ट्रक्चर कंट्रोल के कंसंट्रेशन में होता है। जब एक फर्म के पास बहुत ज़्यादा ट्रैफिक या प्रोटेक्शन होता है—चाहे वह वेब-ट्रैफिक का 20 परसेंट हो या बड़ी कंपनियों का 60 परसेंट—तो सिस्टम के फेल होने के तरीके सिर्फ़ अलग-अलग नहीं, बल्कि ग्लोबल हो जाते हैं।

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

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

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

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

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