जेफिरनेट लोगो

XZ यूटिल्स स्केयर सॉफ्टवेयर सुरक्षा में कठिन सच्चाइयों को उजागर करता है

दिनांक:

XZ यूटिल्स डेटा कम्प्रेशन यूटिलिटी में एक पिछले दरवाजे की हालिया खोज - जो लगभग सभी प्रमुख लिनक्स वितरणों में मौजूद है - एक स्पष्ट अनुस्मारक है कि जो संगठन ओपन सोर्स घटकों का उपभोग करते हैं वे अंततः सॉफ़्टवेयर को सुरक्षित करने की ज़िम्मेदारी लेते हैं।

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

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

ओपन सोर्स आउटसोर्सिंग के समान नहीं है: “सॉफ्टवेयर के ओपन सोर्स अनुरक्षक स्वयंसेवक होते हैं। उद्योग स्तर पर, हमें उनके साथ वैसा ही व्यवहार करने की आवश्यकता है। हमारा अपना सॉफ़्टवेयर है; हम उस सॉफ़्टवेयर के लिए ज़िम्मेदार हैं जिसका हम पुन: उपयोग करते हैं।"

नेक इरादे वाला, कम संसाधन वाला

ओपन सोर्स सॉफ़्टवेयर सुरक्षा पर चिंताएँ किसी भी तरह से नए नहीं हैं. लेकिन इसमें अक्सर जैसी खोजों की आवश्यकता होती है Log4Shell भेद्यता और XZ यूटिल्स में पिछला दरवाजा इससे वास्तव में पता चलता है कि संगठन अपने कोड के घटकों के प्रति कितने संवेदनशील हैं। और अक्सर, कोड अच्छे इरादों वाले लेकिन निराशाजनक रूप से कम संसाधन वाले ओपन सोर्स प्रोजेक्ट्स से आते हैं जिनका न्यूनतम रखरखाव किया जाता है।

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

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

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

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

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

ख़तरा: सकर्मक निर्भरताएँ

A एंडोर द्वारा किया गया अध्ययन 2022 में पाया गया कि 95% ओपन सोर्स कमजोरियाँ तथाकथित ट्रांजिटिव निर्भरता, या सेकेंडरी ओपन सोर्स पैकेज या लाइब्रेरीज़ में मौजूद हैं, जिन पर प्राथमिक ओपन-सोर्स पैकेज निर्भर हो सकता है। अक्सर, ये ऐसे पैकेज होते हैं जिन्हें डेवलपर्स सीधे तौर पर स्वयं नहीं चुनते हैं, बल्कि अपने विकास प्रोजेक्ट में ओपन सोर्स पैकेज द्वारा स्वचालित रूप से नियोजित होते हैं।

"उदाहरण के लिए, जब आप एक मावेन पैकेज पर भरोसा करते हैं, तो परिणामस्वरूप औसतन 14 अतिरिक्त निर्भरताएँ होती हैं जिन पर आप स्पष्ट रूप से भरोसा करते हैं," स्कॉट कहते हैं। "एनपीएम जैसे कुछ सॉफ्टवेयर इकोसिस्टम में यह संख्या और भी बड़ी है, जहां आप अपने भरोसेमंद प्रत्येक के लिए औसतन 77 अन्य सॉफ्टवेयर घटकों का आयात करते हैं।"

उनका कहना है कि ओपन सोर्स जोखिमों को कम करना शुरू करने का एक तरीका इन निर्भरताओं पर ध्यान देना और आप कौन सी परियोजनाएं चुनते हैं, इसके बारे में चयनात्मक होना है।

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

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

सॉफ्टवेयर-संरचना विश्लेषण उपकरण, भेद्यता स्कैनर, ईडीआर/एक्सडीआर सिस्टम और एसबीओएम भी संगठनों को कमजोर और समझौता किए गए खुले स्रोत घटकों की शीघ्र पहचान करने में मदद कर सकते हैं।

खतरे को स्वीकार करना

टाइडलिफ्ट के फिशर का कहना है, "एक्सपोज़र को कम करना सी-सूट में और यहां तक ​​कि बोर्ड स्तर पर भी साझा समझ और स्वीकार्यता के साथ शुरू होता है कि औसत सॉफ़्टवेयर उत्पाद की लगभग 70% सामग्री ऐतिहासिक रूप से ज्यादातर अप्रतिदेय योगदानकर्ताओं द्वारा बनाई गई ओपन सोर्स सॉफ़्टवेयर है।"  

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

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

स्पॉट_आईएमजी

नवीनतम खुफिया

स्पॉट_आईएमजी