यह श्रृंखला का तीसरा एपिसोड है। लेखों की श्रृंखला सॉफ्टवेयर आपूर्ति श्रृंखला पर होने वाले सबसे आम हमलों में से एक है: वे हमले जो सार्वजनिक रजिस्ट्री का दुरुपयोग करते हैं। खुले स्रोत सॉफ्टवेयर घटक। पिछले एपिसोड में विश्लेषण करने के बाद “दुर्भावनापूर्ण पैकेजों की संरचना: रुझान क्या हैं?"दुष्ट तत्व किस प्रकार नए या मौजूदा प्रकाशित घटकों में दुर्भावनापूर्ण व्यवहार को शामिल करते हैं, इस बारे में हम तुरंत कार्रवाई करने और यह जांचने के लिए तैयार हैं कि हम इस तरह से वितरित दुर्भावनापूर्ण सॉफ़्टवेयर को सफलतापूर्वक कैसे रोक सकते हैं, या वैकल्पिक रूप से, गलत दृष्टिकोण अपनाने के कारण होने वाली संभावित गंभीर साइबर घटना से कैसे निपट सकते हैं।"
सुरक्षा के प्रति जागरूक अधिकांश पेशेवरों के पास इस खतरे से निपटने के तरीके के बारे में विचार हैं। हमने सुरक्षा प्रबंधकों को बिना किसी झिझक के यह कहते सुना है कि SCA टूल पहले से ही बता देते हैं कि कोई पैकेज संस्करण मैलवेयर है या नहीं। या फिर यह कि वे जाने-माने, उच्च-समीक्षित सॉफ़्टवेयर घटकों पर निर्भर हैं, जहाँ किसी भी मैलवेयर का तुरंत पता लगाकर उसे हटा दिया जाएगा। वे भेद्यता सुधार स्वचालित रूप से प्राप्त करने के लिए खुले माइनर/पैच संस्करणों का उपयोग करते हैं, और यह खुले स्रोत निर्भरताओं पर जोखिम को कम करने का उचित, अनुशंसित तरीका है, जो "जल्दी पैच लगाओ, बार-बार पैच लगाओसिद्धांत।
इस एपिसोड में, हम यह जानेंगे कि ये विचार गलत क्यों हैं, और किस प्रकार ये गलत धारणाएँ इस आक्रमण तंत्र की लोकप्रियता और संगठनों के सामने आने वाले भारी जोखिम में योगदान दे रही हैं। अंत में, हम यह बताएंगे कि वास्तव में क्या कारगर है, और इसमें कितना प्रयास और संसाधन लगते हैं।
आम गलतफहमी
सॉफ्टवेयर सुरक्षा के क्षेत्र में अपने अनुभव के दौरान, हमने आक्रमण तकनीकों के विकास और सुरक्षा के प्रति जागरूक लोगों के विचारों की व्यापक विविधता देखी। संगठन अक्सर इस खतरे से निपटने के कारगर तरीकों को लेकर गलतफहमी का शिकार हो जाते हैं, इसलिए सबसे पहले हम उन तरीकों पर गौर करेंगे जो कारगर नहीं हैं। गलतफहमियों की यह संक्षिप्त सूची (पूरी नहीं) नीचे दी गई है।
गलतफहमी #1: SCA उपकरण पहले से ही दुर्भावनापूर्ण घटकों की रिपोर्ट करते हैं।
वास्तव में! लेकिन घटना के बाद...जबकि शायद बहुत देर हो चुकी हो अगर उस तत्व का उपयोग सॉफ्टवेयर बिल्ड में किया गया हो, और दुर्भावनापूर्ण तत्वों ने पहले ही किसी डेवलपर या CI/CD मेजबान। हो सकता है कि गुप्त जानकारी लीक हो गई हो, अतिरिक्त मैलवेयर डाउनलोड और इंस्टॉल हो गया हो, और शायद दुश्मन ने अन्यत्र पहुँच प्राप्त कर ली हो।
सॉफ्टवेयर संरचना विश्लेषण (SCAपुराने टूल संभावित ज्ञात कमजोरियों की पहचान करने के लिए डिज़ाइन किए गए थे। आधुनिक टूल सिग्नल-शोर अनुपात को बढ़ाकर यह निर्धारित करने में बहुत अच्छा काम करते हैं कि क्या भेद्यता वास्तव में पहुंच योग्य या शोषण योग्य है। लेकिन वे नए मैलवेयर के खिलाफ बेकार हैं। एक दुर्भावनापूर्ण घटक को ज़ीरो-डे भेद्यता के रूप में सोचें: जब इसके दुर्भावनापूर्ण व्यवहार का पता चलता है, तभी घटक को होल्डिंग रजिस्ट्री में रिपोर्ट किया जाता है, जो एक सुरक्षा टीम द्वारा समीक्षा के बाद दुर्भावनापूर्ण होने की पुष्टि करता है और रजिस्ट्री से हटा दिया जाता है। [1].
उस समय, दुनिया (सहित SCAs) जानता है कि कंपोनेंट (या किसी मौजूदा कंपोनेंट के कुछ संस्करणों) को इंस्टॉल करना या उपयोग करना ठीक नहीं है। लेकिन यह तब होता है जब कंपोनेंट रजिस्ट्री में उपलब्ध नहीं होता है।तृतीय-पक्ष घटकों में, या रजिस्ट्री द्वारा दुर्भावनापूर्ण के रूप में वर्गीकृत घटकों में भी कमजोरियों का पता होना अच्छी बात है, लेकिन दुर्भाग्यवश SCA या फिर सामान्य ऑडिट उपकरण इस संदर्भ में मददगार नहीं होते। जब तक कि SCAऑडिट टूल किसी घटक के आपके संगठन में उपयोग होने से पहले ही यह जान सकता है कि वह दुर्भावनापूर्ण है या नहीं।.
याद रखें, दुर्भावनापूर्ण ओपन-सोर्स घटकों के खिलाफ किसी भी समाधान को उनका पता लगाना होगा। उड़ान परयह अवधि रजिस्ट्री में घटक के प्रकाशित होने और आपके संगठन में घटक (संस्करण) के पहली बार उपयोग किए जाने के बीच की होती है। इसमें पारगमनशील घटक भी शामिल हैं।
भ्रम #2: बिल्ड टाइम पर इंस्टॉलेशन स्क्रिप्ट को नियंत्रित करने से ओपन-सोर्स घटकों के दुर्भावनापूर्ण व्यवहार को रोका जा सकता है।
विभिन्न पैकेज मैनेजर स्क्रिप्ट चलाने की सुविधा प्रदान करते हैं (जो कंपोनेंट टारबॉल में शामिल होती हैं)। [2]), वैध कारणों से, जैसे कि विभिन्न प्लेटफार्मों पर आवश्यक वस्तुओं को संकलित करना, कोड उत्पन्न करना या परीक्षण चलाना, और हम सभी को पता होना चाहिए कि अगर टारबॉल में दुर्भावनापूर्ण स्क्रिप्ट शामिल हैं, या यदि हमलावर अच्छी स्क्रिप्ट के बजाय दुर्भावनापूर्ण स्क्रिप्ट चलाने में सक्षम है, तो इनका दुरुपयोग बुरे तत्वों द्वारा किया जा सकता है।
यह जानते हुए, हम पैकेज मैनेजर को स्क्रिप्ट को अनदेखा करने के लिए कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए, NPM के साथ -Ignore- स्क्रिप्ट ध्वज (या कॉन्फ़िगरेशन प्रॉपर्टी) .npmrc फ़ाइल) इंस्टॉलेशन के दौरान स्क्रिप्ट को छोड़ देती है। इससे कुछ समस्याएँ उत्पन्न हो सकती हैं क्योंकि कई इकोसिस्टम में स्क्रिप्ट चलाना आम बात है: कुछ पैकेज मैनेजर स्क्रिप्ट निष्पादन को अक्षम करने की अनुमति भी नहीं देते हैं (संकेत: प्रॉम्प्ट “कौन से पैकेज मैनेजर इंस्टॉलेशन स्क्रिप्ट के निष्पादन को अक्षम करने की अनुमति नहीं देते हैं?(अपने पसंदीदा एआई में "स्किप डिसेबल" विकल्प का उपयोग करें)। लेकिन यह सामान्य रूप से सुरक्षा प्रदान नहीं करता (हमें यह सुनिश्चित करना होगा कि स्किप डिसेबल कॉन्फ़िगरेशन हर जगह लागू हो)।
और जब दुर्भावनापूर्ण व्यवहार इंस्टॉलेशन स्क्रिप्ट में नहीं बल्कि रनटाइम पर निष्पादित होने वाले सॉफ़्टवेयर में स्थित होता है, तो यह विकल्प अकेले हमारी सुरक्षा नहीं करता है।
भ्रम #3: वर्ज़न पिनिंग दुर्भावनापूर्ण घटकों की स्थापना को रोकता है
जल्दी और बार-बार पैच लगाने के बीच एक समझौता करना पड़ता है। खुले संस्करण (पैकेज मैनेजर को सुरक्षा संबंधी सुधारों के लिए उपलब्ध होने पर नए अपडेट स्वचालित रूप से स्थापित करने की अनुमति देना) और संस्करण पिनिंग (किसी सॉफ़्टवेयर के लिए सभी प्रत्यक्ष और पारगमन निर्भरताओं को एक निश्चित संस्करण पर रखना)। सुरक्षा सिद्धांत अड़ियल और कभी-कभी विरोधाभासी होते हैं, जैसा कि "जल्दी पैच करो, बार-बार पैच करो" के साथ होता है। “अपग्रेडिंग को हल्के में नहीं लेना चाहिए”कुछ पैकेज मैनेजर सर्वर रेंज के साथ स्वचालित अपडेट करने को अनुशंसित तरीका मानते हैं। अगर आप भी हानिकारक अपडेट प्राप्त करना चाहते हैं तो यह अच्छा है! हाँ, सुरक्षा संबंधी सुधारों को प्राप्त करने और कमजोरियों को जल्द से जल्द दूर करने के लिए घटकों को अपडेट करना आवश्यक है, लेकिन... पैकेज मैनेजर को इसे कभी भी स्वचालित रूप से करने न दें।
भ्रम संख्या 4: विश्वसनीय घटकों का उपयोग करना सुरक्षित है। किसी भी दुर्भावनापूर्ण संस्करण का तुरंत पता लगा लिया जाएगा, उसका खुलासा किया जाएगा और उसे हटा दिया जाएगा।
किसी कंपोनेंट पर भरोसा क्यों किया जाता है? शायद इसलिए क्योंकि यह बहुत लोकप्रिय है, कई लोग इसकी कमजोरियों की तलाश में रहते हैं, इसके रखरखाव में बड़ी संख्या में योगदानकर्ता हैं, और कई मुख्य मेंटेनर हैं जो हर चीज की सावधानीपूर्वक समीक्षा करते हैं। pull requestsलेकिन वास्तविकता बिल्कुल अलग है। कुछ आवश्यक घटकों का रखरखाव एक ही अवैतनिक डेवलपर द्वारा किया जाता है। व्यापक रूप से उपयोग किए जाने वाले फ्रेमवर्क में कुछ नियमित योगदानकर्तातेजी से घटती संख्या के साथ commitप्रति अनुरक्षक (लोकप्रिय परियोजनाओं में योगदानकर्ताओं की एक लंबी श्रृंखला होती है जो कुछ अस्थायी योगदानकर्ता होते हैं) commit और कभी वापस नहीं आते)। और एक ही मेंटेनर वाले लोकप्रिय प्रोजेक्ट्स की भरमार है।
कल्पना कीजिए कि आप कह रहे हैं "ओह, हम स्प्रिंग बूट / एंगुलर / रिएक्ट / पायटॉर्च / आधिकारिक बेस डॉकर इमेज का उपयोग कर रहे हैं, इसलिए जिस जोखिम की आप बात कर रहे हैं वह काफी कम है।" शायद यह सच है, हम सुरक्षा विक्रेता हर समय डर फैलाते रहते हैं, और किसी विवादास्पद जोखिम को कम करने के लिए विकास टीमों के काम में दखल देना बेवकूफी है। आप शायद जोखिम स्वीकृति पैराग्राफ (अगले भाग में) पर जाना चाहेंगे और सोचेंगे कि काम पूरा हो गया। दुर्भाग्य से, सबसे लोकप्रिय घटक बुरे तत्वों के निशाने पर होते हैं, और उदाहरण के लिए, लोकप्रिय PyTorch लाइब्रेरी पर हमला हुआ अतीत में.
"तुरंत पता लगाया गया, खुलासा किया गया और हटा दिया गया"। किसी नए दुर्भावनापूर्ण घटक को सार्वजनिक रजिस्ट्री से हटाने में कई दिन लग जाते हैं। रजिस्ट्री किसी घटक संस्करण को हटाने में सावधानी बरतती है, जो कि अच्छी बात है। हमारे अनुभव के अनुसार, हमारी ओर से रिपोर्ट किए जाने के बाद, रजिस्ट्री द्वारा प्रभावित संस्करण को हटाने में औसतन 39 घंटे लगते हैं, जो डेढ़ दिन से अधिक है। कुछ दुर्भावनापूर्ण घटक ऐसे भी हैं जो हमारी प्रारंभिक रिपोर्ट के एक सप्ताह बाद तक रजिस्ट्री में मौजूद रहते हैं। और कुछ मामलों में, घटक को तभी हटाया जाता है जब कोई पीड़ित या घटना प्रतिक्रिया कंपनी उस घटक से जुड़ी किसी घटना की रिपोर्ट करती है।
दुर्भावनापूर्ण घटकों के विरुद्ध क्या काम नहीं करता है
कोई भी अस्पष्ट दृष्टिकोण बुरी तरह विफल हो जाएगा। यह निश्चित है कि आप इस खतरे से जुड़े जोखिम के लिए प्रभावी प्रतिउपाय प्रदान नहीं कर रहे हैं।
परंपरागत SCA ये उपकरण आपको ज्ञात मैलवेयर के बारे में जानकारी देते हैं, लेकिन इनमें जोखिम का दायरा बहुत बड़ा होता है। जब तक ये उपकरण सक्रिय रूप से मैलवेयर का पता लगाकर दुर्भावनापूर्ण घटकों को ब्लॉक नहीं करते, तब तक ये इस खतरे के खिलाफ कारगर नहीं होते।
इंस्टॉलेशन स्क्रिप्ट को डिसेबल करने से मदद मिल सकती है, लेकिन इसे हर उस जगह लागू करना होगा जहां किसी कंपोनेंट को इंस्टॉल करने की आवश्यकता है। यही बात वर्जन पिनिंग पर भी लागू होती है, क्योंकि वर्जन को किसी सुरक्षित प्रारंभिक स्थिति से हमेशा के लिए पिन नहीं किया जा सकता।
यह मान लेना कि लोकप्रिय घटकों पर इतना ध्यान दिया जाता है कि आपूर्ति श्रृंखला पर हमले के दौरान उनमें अनपेक्षित व्यवहार उत्पन्न नहीं किया जा सकता और लगभग तुरंत पता लगाकर नुकसान को रोका जा सकता है, भोलापन और जोखिम भरा है। आप जोखिम भरा जीवन नहीं जीना चाहेंगे, है ना?
अगर आप यहीं रुक जाते हैं, तो जोखिम स्वीकृति आप बस यही कर सकते हैं: यह एक डी हैcisयह वह जानकारी है जिसे आपके खतरे के मॉडल/जोखिम मूल्यांकन में प्रलेखित किया जाना चाहिए, जिसमें जोखिम को स्वीकार करने का तर्क और इसके संभावित निहितार्थ शामिल हैं। प्रबंधन और अन्य संबंधित पक्षों को इसके बारे में सूचित करके जागरूकता बढ़ाएं। आकस्मिकता किसी दुर्भावनापूर्ण घटक को आपके सॉफ़्टवेयर में स्थापित या शामिल किए जाने पर हमले की योजना बनाई जा सकती है, लेकिन यह मुश्किल है क्योंकि हमलावरों के पास हमला करने के कई रास्ते होते हैं। दुर्भावनापूर्ण घटक के उपयोग पर आधारित आपूर्ति श्रृंखला हमले का विवरण घटना के सार्वजनिक प्रकटीकरण को काफी हद तक बदल देगा, जो संभवतः आपके संगठन के नियामक ढांचे के तहत अनिवार्य है। आप इस पर भी विचार कर सकते हैं। क्षतिपूर्ति नियंत्रण or स्थानांतरण जोखिम उदाहरण के लिए, बीमा के साथ।
हालांकि, ऐसे उपाय मौजूद हैं जो इस खतरे से निपटते हैं और यदि आप जोखिम स्वीकार्यता से संतुष्ट नहीं हैं तो इन पर विचार किया जाना चाहिए। कृपया आगे पढ़ें।
दुर्भावनापूर्ण घटकों का उपयोग करके किए गए हमलों के खिलाफ क्या कारगर है?
सॉलिड वर्जन हैंडलिंग
नियंत्रित और सूचित संस्करण अपडेट के साथ संस्करण पिनिंग ही सही तरीका है, ताकि मैलवेयर से बचाव करते हुए सुरक्षा कमजोरियों को दूर किया जा सके। लेकिन तीसरी गलतफहमी याद रखें: केवल संस्करण पिनिंग ही नए संस्करणों से आने वाले दुर्भावनापूर्ण कोड को रोकने के लिए पर्याप्त नहीं है, क्योंकि भविष्य में आपको किसी भी प्रत्यक्ष या अप्रत्यक्ष निर्भरता के संस्करणों को अपडेट करना होगा। उस समय आपको इस बात का पुख्ता सबूत चाहिए होगा कि सभी संशोधित संस्करणों में मैलवेयर नहीं है।
प्रारंभिक चेतावनी
दुर्भावनापूर्ण घटकों की समस्या से निपटने का एक तरीका प्रारंभिक चेतावनी प्रणाली (जिसे यहां नाम दिया गया है) है। मैलवेयर की प्रारंभिक चेतावनी (जैसे कि MEW), जहां प्रकाशित नए संस्करणों (नए या मौजूदा घटकों के लिए) का विश्लेषण एक पहचान इंजन द्वारा किया जाता है, जो पर्याप्त सबूत मिलने पर नए संस्करण को संभावित रूप से दुर्भावनापूर्ण के रूप में वर्गीकृत कर सकता है।
यहां स्वचालन अत्यंत आवश्यक है, क्योंकि वर्तमान प्रकाशन दर पर सभी नए घटकों की मैन्युअल समीक्षा करना असंभव है। इसलिए, पहचान इंजन को कई तकनीकों को संयोजित करने की आवश्यकता है, जिनमें संभवतः स्थैतिक, गतिशील और क्षमता विश्लेषण, उपयोगकर्ता प्रतिष्ठा और घटक मेटाडेटा और टारबॉल सामग्री के बीच या टारबॉल और स्रोत भंडार के बीच विसंगतियों से प्राप्त साक्ष्य शामिल हैं, जहां से घटक के आने की संभावना है।
प्रत्येक श्रेणी के लिए अलग अंधेरा क्षेत्र प्रकाशन समय और इंजन द्वारा घटक सामग्री का विश्लेषण करने के बीच का समय कुछ मिनटों से अधिक नहीं होना चाहिए। इस योजना को संशोधित किया जा सकता है, उदाहरण के लिए, नए घटकों को सॉफ़्टवेयर बिल्ड में स्थापित और उपयोग करने की अनुमति देने से पहले उनके विश्लेषण की प्रतीक्षा करना। pipelineया आवश्यकता पड़ने पर उनका विश्लेषण करें। किसी दिए गए संस्करण में एक घटक अपरिवर्तनीय होता है। [3]इसलिए इसका विश्लेषण केवल एक बार ही करना आवश्यक है।
पूर्ण स्वचालन संभव नहीं है, और संभावित रूप से दुर्भावनापूर्ण घटकों के लिए सुरक्षा समीक्षा की आवश्यकता है। डिजिटल रामबाण के समर्थकों से सावधान रहेंसंदिग्ध कंपोनेंट में मैलवेयर होने की पुष्टि करने के लिए कृत्रिम बुद्धिमत्ता (AI) और मशीन लर्निंग अभी पर्याप्त रूप से विकसित नहीं हैं। बेशक, मशीन लर्निंग कच्चे साक्ष्यों से इनपुट कंपोनेंट को वर्गीकृत करने में डिटेक्शन इंजन की महत्वपूर्ण भूमिका निभाती है, लेकिन एक बार कंपोनेंट को "क्वारंटाइन" कर दिए जाने के बाद, मैलवेयर से निपटने का अनुभव रखने वाली सुरक्षा टीम द्वारा मैन्युअल समीक्षा ही अंतिम निर्णय होती है। यह समीक्षा किसी भी संभावित मैलवेयर की पुष्टि करती है या उसे सुरक्षित के रूप में पुनः वर्गीकृत करती है। और इसमें कुछ ही घंटे लगते हैं।
रजिस्ट्री दुर्भावनापूर्ण संस्करण/घटक की रिपोर्ट करती है; रजिस्ट्री इसकी पुष्टि करने के लिए समीक्षा करती है और फिर इसे सार्वजनिक रूप से प्रकट करने और रजिस्ट्री से हटाने की प्रक्रिया शुरू करती है। कुछ रजिस्ट्रियां एक सुरक्षा होल्डिंग पैकेज रखती हैं। यहां समय सीमा प्रकाशन के बाद से दिनों या हफ्तों में है, जिसे 'प्रवास समय'या'एक्सपोजर विंडो'अधिकांश दुर्भावनापूर्ण घटकों के लिए।
क्या किसी कंपोनेंट के वर्जन के दुर्भावनापूर्ण होने का पता लगाना संभव है?
इसलिए, प्रारंभिक चेतावनी के लिए, हमें इस प्रश्न का संतोषजनक उत्तर देना होगा: मैं कैसे जान सकता हूँ कि कोई लाइब्रेरी या पैकेज दुर्भावनापूर्ण है या नहीं? दुर्भावनापूर्ण व्यवहार के पर्याप्त सबूत कैसे जुटाए जाएँ? यह संभव है, लेकिन कठिन है, क्योंकि विरोधी पकड़े जाने से बचने के लिए बहुत चालाकी का इस्तेमाल करते हैं। विभिन्न दृष्टिकोण हैं, जिनमें से प्रत्येक के अपने फायदे और नुकसान हैं।
स्थैतिक विश्लेषण यह घटक को चलाए बिना ही सभी निष्पादन पथों की जांच कर हमलावरों द्वारा उपयोग की जाने वाली तकनीकों का पता लगा सकता है, और डी-ऑबफस्केशन या डिक्रिप्शन जैसे प्रीप्रोसेसिंग कार्य कर सकता है। चूंकि हमलावर अपनी शरारतों को छिपाने की कोशिश करते हैं, इसलिए ऑबफस्केशन के प्रयास वास्तव में मैलवेयर के सबूत होते हैं (लेकिन ध्यान दें कि वैध घटक बौद्धिक संपदा को संरक्षित करने के लिए कोड को ऑबफस्केट करते हैं, जो "खुला स्रोतकेवल कुछ ही अत्यधिक परिष्कृत हमलों को, जिनमें मजबूत अस्पष्टीकरण का उपयोग किया जाता है, सैंडबॉक्सिंग की आवश्यकता होती है, लेकिन ऐसा मजबूत अस्पष्टीकरण दुर्भावना का स्पष्ट संकेत है। कृपया ध्यान दें कि पारंपरिक SAST ये उपकरण अनजाने में उत्पन्न होने वाली कमजोरियों के लिए डिज़ाइन किए गए थे, न कि बैकडोर जैसी दुर्भावनापूर्ण मंशाओं के लिए।
गतिशील विश्लेषण यह घटक को चलाता है और रनटाइम को नियंत्रित करके प्रतिक्रिया की जांच करता है, आमतौर पर एक सैंडबॉक्स वातावरण प्रदान करके। कुछ शर्तों के तहत ट्रिगर किया गया दुर्भावनापूर्ण व्यवहार बिना पता चले ही बच सकता है: कृपया ध्यान दें कि मैलवेयर बचाव तकनीकों का उपयोग कर सकता है जैसे कि वर्चुअलाइजेशन/सैंडबॉक्स चोरी यह केवल तभी सक्रिय होता है जब इसकी निगरानी नहीं की जा रही हो, और यह किसी भी स्थैतिक विश्लेषण इंजन के लिए दुर्भावनापूर्ण गतिविधि का एक स्पष्ट संकेत भी है।
क्षमताओं का विश्लेषण यह विश्लेषण घटक की गतिविधियों पर विचार करता है: यह कहाँ से जुड़ता है, किन फ़ाइलों तक पहुँचता है, कौन से कमांड या प्रोग्राम चलाए जाते हैं, टर्मिनल या डिवाइस पर कौन सा इनपुट/आउटपुट किया जाता है, या कौन से सिस्टम कॉल किए जाते हैं। व्यवहार की इस फ़िंगरप्रिंटिंग की तुलना (मौजूदा घटक के लिए) विभिन्न संस्करणों में की जा सकती है, इसलिए जब कोई अप्रत्याशित व्यवहार पाया जाता है, तो यह सबूत नए संस्करण में संभावित दुर्भावनापूर्ण गतिविधि के संदेह को बढ़ा सकता है। यह दृष्टिकोण उन प्राथमिक उपचार चरणों का अनुसरण करता है जिनका पालन सुरक्षा विश्लेषक संभावित मैलवेयर का सामना करने पर करते हैं: एक निरीक्षण का उपयोग करके तार या इसी तरह के अन्य उपकरण। यह दृष्टिकोण ट्रिगर करने वाली स्थितियों की परवाह किए बिना दुर्भावनापूर्ण व्यवहार का पता लगाता है और तब भी काम करता है जब कोई स्रोत कोड उपलब्ध न हो।
संदर्भ विश्लेषण यह जानकारी इकट्ठा करता है कि कंपोनेंट कैसे और किसके द्वारा प्रकाशित किया गया था। दुर्भावनापूर्ण गतिविधियों में अक्सर नए उपयोगकर्ता खातों का उपयोग किया जाता है, जिन पर कोई सख्त जांच प्रक्रिया लागू नहीं होती। पिछली गतिविधियों पर नज़र रखने से मूल उपयोगकर्ता के बारे में जानकारी मिल सकती है, खासकर उन असामान्यताओं के बारे में जो संभावित सुरक्षा उल्लंघन का संकेत दे सकती हैं। प्रतिष्ठा कमाना बहुत मुश्किल है और खोना बहुत आसान! बिना किसी पिछली गतिविधि वाला उपयोगकर्ता तटस्थ होता है, लेकिन कर्म का फल बुरे कर्मों के फल स्वरूप मिलता है। हैक्टिविस्टों या सामान्य उपयोगकर्ताओं, जिनके प्रकाशन क्रेडेंशियल चोरी हो गए हैं, पर सावधानीपूर्वक नज़र रखनी चाहिए।
एक अन्य प्रासंगिक जानकारी स्रोत रिपॉजिटरी और टारबॉल की सामग्री के बीच कोई विसंगति है, जिसका उपयोग घटक टारबॉल बनाने के लिए किया गया था। साथ ही, अच्छी प्रथाओं का पालन करना, जैसे कि स्रोत रिपॉजिटरी में टैग या रिलीज़ बनाना जो सार्वजनिक रजिस्ट्री में प्रकाशित घटक के संस्करणों से मेल खाते हों। जब किसी विशेष स्रोत रिपॉजिटरी में commit यदि किसी कंपोनेंट को रिलीज़ टैग किया जाता है, और फिर अचानक कोई संस्करण उसका पालन करने में विफल हो जाता है, तो यह अपने आप में इस बात का पुख्ता सबूत है कि कंपोनेंट दूषित हो सकता है: दुर्भावनापूर्ण हमलावर ने कंपोनेंट को प्रकाशित करने के लिए उपयोग किए गए खाते से समझौता किया हो सकता है, लेकिन उसके पास स्रोत कोड रिपॉजिटरी में लिखने की अनुमति नहीं है। इन नियमों का उपयोग करके कई हमलों का नियमित रूप से पता लगाया जाता है: उदाहरण के लिए, खाता बही हमला इन बातों का आसानी से पता लगाया जा सकता है। इसलिए, संदर्भ विश्लेषण प्रकाशन प्रक्रिया में ऐसी विसंगतियों की पहचान करता है।
निर्भरता फ़ायरवॉलिंग
एक अलग तरीका यह है कि आपके सॉफ़्टवेयर में उपयोग किए जाने वाले सभी डिपेंडेंसी ग्राफ़ के लिए घटकों की एक व्यापक श्वेतसूची हो, ताकि किसी भी बिल्ड में pipeline आपके संगठन में केवल अनुमोदित घटक संस्करणों को ही स्थापित और उपयोग किया जा सकता है।फ़ायरवॉलयह नियम एक आंतरिक रजिस्ट्री के माध्यम से लागू किया जाता है, जहाँ अनुमत घटक संस्करणों के लिए टारबॉल उपलब्ध कराए जाते हैं (कैश किए जाते हैं या प्रॉक्सी के माध्यम से)। कृपया ध्यान दें कि कोई भी श्वेतसूची तब तक काम नहीं करेगी जब तक आपके पास किसी भी नए संस्करण को यथोचित रूप से सुरक्षित के रूप में वर्गीकृत करने की तकनीक न हो, ताकि उसे श्वेतसूची में जोड़ा जा सके।
कृपया ध्यान दें कि प्रारंभिक चेतावनी (नए संस्करण के प्रकाशन के तुरंत बाद शीघ्र पता लगाना) को उस जानकारी का सक्रिय रूप से उपयोग करने के किसी तरीके के साथ जोड़ा जाना चाहिए ताकि बिल्ड को प्रभावित करने वाले घटक को ब्लॉक किया जा सके। pipelineया डेवलपर्स की मशीनों [4]हम इसे “ कहते हैंनिर्भरता फ़ायरवॉलिंग": स्वचालित बिल्ड को दुर्भावनापूर्ण पैकेजों से बचाने के लिए एक संगरोध तंत्र। आंतरिक पैकेज और इमेज रजिस्ट्री संगठनों को बाहरी खतरों से बचाने के लिए अच्छे हैं, लेकिन संगरोध को प्रभावी बनाने के लिए पर्याप्त मजबूत सबूत आवश्यक हैं।
रनटाइम सैंडबॉक्सिंग
प्रकाशन के समय गड़बड़ी का पता लगाने का एक वैकल्पिक तरीका रनटाइम पर व्यवहार का विश्लेषण करना है। इसका उद्देश्य सॉफ़्टवेयर से अपेक्षित व्यवहार को समझना और पाई गई किसी भी गड़बड़ी का पता लगाना (या उसे रोकना) है। इस कार्यप्रणाली में रनटाइम को मॉनिटर करने या ब्लॉक करने के लिए उपकरण लगाने की समस्या है, और यह एक आशाजनक विचार है जिसे दुर्भावनापूर्ण घटकों से बचाव के लिए सुरक्षा तंत्रों में शामिल किया जाएगा।
एक व्यापक रणनीति तैयार करना
अनुशंसित रणनीति में सॉफ़्टवेयर विकास प्रक्रिया में विभिन्न तकनीकों को संयोजित करना आवश्यक है, ताकि संस्करण अपडेट पर नियंत्रण रखते हुए दुर्भावनापूर्ण घटकों को रोका जा सके। महत्वपूर्ण कमियों को दूर करने के लिए संस्करण अपडेट करते समय स्वचालित संक्रमण से बचने के लिए संस्करण पिनिंग को लागू करना आवश्यक है; संस्करण अपडेट के दौरान प्रत्यक्ष और अप्रत्यक्ष निर्भरताओं का त्वरित और प्रभावी मूल्यांकन करना ताकि यह सुनिश्चित किया जा सके कि उनमें मैलवेयर नहीं है। ज्ञात दुर्भावनापूर्ण घटकों पर निर्भर सॉफ़्टवेयर बिल्ड को ब्लॉक किया जाना चाहिए। और इन सभी का सख्ती से पालन किया जाना चाहिए।
जब संभव हो, तो वर्ज़न पिनिंग का उपयोग करें, क्योंकि इससे बिल्ड को अधिक आसानी से दोहराया जा सकता है। नियंत्रित, मैन्युअल रूप से अनुमोदित संस्करण अपडेट के साथ संस्करण पिनिंग, तथा सहायक प्रौद्योगिकी द्वारा सहायता प्राप्तयह आकलन करना आवश्यक है कि क्या अपडेट मैलवेयर लाता है या सॉफ़्टवेयर को बाधित करता है, और मैलवेयर संक्रमण से बचने के साथ-साथ कमजोरियों को ठीक करने के लिए अपडेट करने में सामंजस्य स्थापित करना चाहिए। टूलिंग इसमें मदद कर सकती है, (1) यह निर्धारित करके कि कौन सी कमजोरियाँ वास्तव में महत्वपूर्ण हैं (पहुँच योग्य और शोषण योग्य, हमलावरों द्वारा लक्षित किए जाने का उच्च जोखिम), (2) उन लक्षित संस्करणों का चयन करके जो वर्तमान घटक उपयोगों के साथ संगत हैं और सॉफ़्टवेयर को बाधित नहीं करते हैं, (3) उन लक्षित संस्करणों का चयन करके जिनमें दुर्भावनापूर्ण व्यवहार नहीं है, और (4) प्रत्यक्ष और अप्रत्यक्ष निर्भरताओं के लिए संस्करण अपडेट को सरल बनाकर, मैनिफेस्ट फ़ाइलों में ऐसे परिवर्तन सुझाकर जिन्हें शीघ्रता से अनुमोदित किया जा सके। चरण (3) के लिए दुर्भावनापूर्ण घटकों के बारे में उनकी प्रकाशन तिथि के जितना संभव हो सके सटीक जानकारी की आवश्यकता होती है।
निर्भरताओं को अपडेट करने की यह प्रक्रिया अवश्य होनी चाहिए से लागू और सत्यापित सभी स्थानों पर। प्रक्रिया का दस्तावेजीकरण किया जाना चाहिए, और इसमें शामिल सभी पक्षों को प्रशिक्षित किया जाना चाहिए, क्योंकि अक्सर विकास और सॉफ्टवेयर निर्माण/तैनाती का कार्य बाहरी एजेंसियों को सौंपा जाता है। CI/CD pipelineइसमें तदनुसार संशोधन किया जाना चाहिए, ताकि स्वचालन किसी दुर्भावनापूर्ण अप्रत्यक्ष निर्भरता को निर्माण में शामिल होने से रोक सके: guardrails किसी डिपेंडेंसी में संभावित मैलवेयर के पर्याप्त सबूत मिलने पर बिल्ड को ब्लॉक करना ही अनुशंसित तरीका है।
यदि आपके संगठन में एक आंतरिक रजिस्ट्री है जो अनुमत घटक संस्करणों को रखने के लिए एक सुरक्षा प्रॉक्सी के रूप में कार्य करती है, तो आपको किसी अनुरोधित घटक को अनुमति सूची में जोड़ने से पहले उसकी जांच करने के लिए (अन्य मानदंडों के अलावा) दुर्भावनापूर्ण घटकों के बारे में जानकारी प्राप्त करनी होगी।
ओपन-सोर्स सॉफ्टवेयर का सुरक्षित रूप से उपयोग करना आसान नहीं है, और मैलवेयर के खतरे को पूरी तरह से ध्यान में रखना होगा, साथ ही कमजोरियों से निपटने के लिए भी उतना ही प्रयास करना होगा।
एक अंतिम नोट: स्रोत उत्पत्तिकंपोनेंट के निर्माण के समय उत्पन्न होने वाले सॉफ़्टवेयर प्रमाणों के रूप में, आर्टिफैक्ट (कंपोनेंट टारबॉल) को उसके स्रोत और निर्माण प्रक्रिया से जोड़ने के प्रयास में एक और महत्वपूर्ण कड़ी है। ध्यान दें कि स्रोत स्नैपशॉट + निर्माण वातावरण और संबंधित सॉफ़्टवेयर आर्टिफैक्ट (विश्वसनीय निर्माण प्रणाली द्वारा हस्ताक्षरित) के बीच यह लिंक यह सुनिश्चित नहीं करता कि कंपोनेंट में दुर्भावनापूर्ण व्यवहार नहीं है, लेकिन इससे अपराधियों के लिए मैलवेयर डालना कठिन हो जाता है। और ओपन सोर्स कंपोनेंट के उपयोग के लिए स्रोत सत्यापन को एक सामान्य आवश्यकता बनाना एक लंबा समय लेगा, और केवल हाल ही में एनपीएम में जोड़ा गयाउन भरोसेमंद बिल्ड और डिप्लॉय सिस्टम को छेड़छाड़-रोधी बनाना, या बिल्ड में किसी भी तरह की छेड़छाड़ का पता लगाना एक अलग मुद्दा है, जो इस पोस्ट के दायरे से बाहर है।
आगे पढ़ने के लिए
द नेक्स्ट एपिसोड़ ओपन सोर्स दुर्भावनापूर्ण पैकेज: ज़ाइगेनी दृष्टिकोण हम Xygeni में अपनी रणनीति प्रस्तुत करेंगे। मैलवेयर की प्रारंभिक चेतावनी (MEW) सिस्टम। सार्वजनिक पैकेज और इमेज रजिस्ट्री में नए पैकेज संस्करणों को स्कैन किया जाता है और स्थैतिक, गतिशील क्षमताओं और प्रासंगिक विश्लेषण के संयोजन का उपयोग करके साक्ष्य प्राप्त किए जाते हैं। उपयोगकर्ता की प्रतिष्ठा और स्रोत कोड रिपॉजिटरी में परिवर्तनों के इतिहास के साथ संयुक्त साक्ष्य, किसी घटक को उच्च जोखिम और संभावित रूप से दुर्भावनापूर्ण श्रेणियों में पूरी तरह से स्वचालित रूप से वर्गीकृत करने की अनुमति देता है। सिस्टम पैकेजों से एकत्रित पिछले साक्ष्यों से सीखता है ताकि गलत पहचान की संभावना को न्यूनतम किया जा सके।
सदस्यता प्राप्त संगठनों को उन घटकों के लिए चेतावनी सूचना मिलती है जिनका वे प्रत्यक्ष या अप्रत्यक्ष रूप से उपयोग कर रहे हैं, जब किसी दुर्भावनापूर्ण संस्करण को वर्गीकृत किया जाता है। इसके बाद हमारे विश्लेषकों द्वारा मैन्युअल विश्लेषण किया जाता है, जो वर्गीकरण की पुष्टि या अस्वीकृति करता है। पुष्टि किए गए मैलवेयर के मामले में, सार्वजनिक रजिस्ट्री को सूचित किया जाता है ताकि वह अपना विश्लेषण कर सके और आमतौर पर दुर्भावनापूर्ण संस्करण को हटा सके या अतिरिक्त कार्रवाई कर सके, जैसे कि संबंधित उपयोगकर्ता खाते को ब्लॉक करना या हटाना।
हम समझाएंगे कि हम NPM, PyPI, GitHub और ओपन सोर्स इकोसिस्टम के अन्य प्रमुख इंफ्रास्ट्रक्चर को कैसे मदद कर रहे हैं ताकि प्रकाशित किसी नए दुर्भावनापूर्ण घटक के सक्रिय रहने की अवधि को कम किया जा सके, जब तक कि उसे मैलवेयर के रूप में पुष्टि न हो जाए और रजिस्ट्री से हटा न दिया जाए। साथ ही, हम यह भी बताएंगे कि संगठन MEW सिस्टम से कैसे लाभ उठा सकते हैं और ओपन सोर्स घटकों से जुड़े सॉफ्टवेयर सप्लाई चेन हमलों से बेहतर सुरक्षा प्राप्त कर सकते हैं।
- [1] खैर, कंपोनेंट के उपयोगकर्ताओं को यह जांचने की आवश्यकता है कि कंपोनेंट टारबॉल कहीं कैश किया गया है या पंजीकृत है, उदाहरण के लिए किसी आंतरिक रजिस्ट्री में, ताकि इस समस्या का निवारण हो सके।
- [2] पैकेज किए गए कंपोनेंट में एक मैनिफेस्ट शामिल होता है जो इसकी सामग्री और मेटाडेटा, सोर्स या कंपाइल किया गया कोड, इंस्टॉलेशन स्क्रिप्ट और टेस्ट सूट जैसी अतिरिक्त वस्तुओं को पैकेजिंग प्रारूप के अनुसार और आमतौर पर संपीड़ित रूप में घोषित करता है। इसे "कंपोनेंट टारबॉल" कहा जाता है।
- [3] भले ही दुर्भावनापूर्ण तत्व रजिस्ट्री में हुई किसी खामी के कारण प्रकाशित घटक को संशोधित करने में सक्षम हो, लेकिन विश्लेषण पूरा होने के बाद एक साधारण क्रिप्टोग्राफिक डाइजेस्ट टारबॉल में किसी भी बदलाव का पता लगा सकता है।
- [4] ध्यान रखें कि कुछ दुर्भावनापूर्ण घटक इंस्टॉलेशन के समय चलते हैं, इसलिए यह उन डेवलपर नोड्स को प्रभावित कर सकता है जो अनजाने में "npm install X" कमांड चलाते हैं, जिसमें X एक दुर्भावनापूर्ण घटक होता है।
