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