सामान्य सॉफ़्टवेयर आपूर्ति श्रृंखला जोखिम और उन्हें कैसे कम करें

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

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

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

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

सॉफ़्टवेयर आपूर्ति श्रृंखलाओं में ज्ञात कमज़ोरियाँ

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

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

निम्न कारणों से अनुप्रयोगों में कमजोरियाँ आ सकती हैं:

 

  • आपके द्वारा लिखा गया कोड: आपके द्वारा स्वयं लिखे गए कस्टम कोड में खराब सुरक्षा प्रथाएँ
  • आप किसके साथ निर्माण करते हैं: ऐप्स बनाने के लिए उपयोग किए जाने वाले सॉफ़्टवेयर डेवलपमेंट टूल से समझौता किया जा सकता है, जिससे आपका सॉफ़्टवेयर सुरक्षा कमजोरियों के संपर्क में आ सकता है
  • आप क्या खरीदते हैं: ऐप डेवलपमेंट के लिए उपयोग किए जाने वाले कुछ ऑफ-द-शेल्फ सॉफ़्टवेयर-ए-ए-सर्विस (SaaS) एप्लिकेशन में कमजोरियां हो सकती हैं
  • आप क्या उपयोग करते हैं: कई एप्लिकेशन तृतीय-पक्ष ओपन-सोर्स लाइब्रेरी पर निर्भर करते हैं जो आपकी आपूर्ति श्रृंखला में कमजोर कड़ी के रूप में काम कर सकते हैं।

 

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

एंबेडेड दुर्भावनापूर्ण कोड पैकेज

सॉफ़्टवेयर आपूर्ति श्रृंखला हमले में हमलावर जो काम करते हैं उनमें से एक प्रभावित समापन बिंदु को दुर्भावनापूर्ण सॉफ़्टवेयर से संक्रमित करना है। यह मैलवेयर एक वायरस, रैंसमवेयर, ट्रोजन हॉर्स या स्पाइवेयर हो सकता है जो प्रभावित सॉफ़्टवेयर और कंप्यूटर सिस्टम पर कहर बरपा सकता है।

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

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

संवेदनशील डेटा का निष्कासन

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

हमलावर तीसरे पक्ष के विक्रेता से चुराए गए क्रेडेंशियल्स का उपयोग करके टारगेट के सिस्टम में घुस गए। इस हमले ने उन्हें टारगेट के ग्राहक सेवा डेटाबेस तक अनधिकृत पहुंच प्रदान की, जिससे उन्हें ग्राहकों के नाम, फोन नंबर, ईमेल पते, भुगतान कार्ड की जानकारी और अन्य संवेदनशील डेटा पर कब्जा करने की अनुमति मिली। 41 मिलियन लक्षित ग्राहकों के भुगतान कार्ड की जानकारी हमलावर के सर्वर तक पहुंचा दी गई थी, जबकि 60 मिलियन से अधिक ग्राहकों की संपर्क जानकारी उजागर हो गई थी।

रिमोट कोड निष्पादन

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

typosquatting

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

निर्भरता भ्रम

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

सॉफ़्टवेयर आपूर्ति श्रृंखला में जोखिमों को कैसे कम करें?

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

 

अपने सॉफ़्टवेयर का ऑडिट करें

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

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

अभी हाल ही में, 2020 सोलरविंड्स हमले के बाद, जिसने कई अमेरिकी सरकारी एजेंसियों को प्रभावित किया, संयुक्त राज्य अमेरिका की संघीय सरकार ने सॉफ्टवेयर ऑडिट को कानूनी आवश्यकता बना दिया है अमेरिकी सरकारी एजेंसी को सॉफ़्टवेयर बेचने वाली प्रत्येक कंपनी के लिए। आपको अपने सभी सिस्टम के लिए भी ऐसा ही करना चाहिए। आपके सभी सॉफ़्टवेयर निर्भरताओं का स्पष्ट रिकॉर्ड रखना यह जानने का एकमात्र तरीका है कि आपका सिस्टम आपूर्ति श्रृंखला हमलों के जोखिम के संपर्क में है या नहीं।

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

स्वचालित ऑडिटिंग

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

सामग्री का एक सॉफ्टवेयर बिल तैयार करें

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

सामग्रियों का बिल तैयार करने की अवधारणा बिल्कुल नई नहीं है। ऐतिहासिक रूप से, इसकी उत्पत्ति विनिर्माण की दुनिया से हुई है। यहां, प्रत्येक निर्मित उत्पाद को सामग्री का एक बिल मिलता है जो उस उत्पाद की निर्माण प्रक्रिया में शामिल सभी वस्तुओं की एक सूची के रूप में कार्य करता है।

SBOM पर छवि

 

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

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

एक जोखिम प्रबंधन ढांचा विकसित करें

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

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

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

निष्कर्ष

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