व्यवसाय विस्तृत अनुशंसाओं का पालन कर सकते हैं और मौजूदा पैच लागू कर सकते हैं और log4j की तत्काल प्रतिक्रिया में सर्वोत्तम अभ्यास लागू कर सकते हैं। लेकिन दूसरे चरण में, उन्हें सॉफ्टवेयर सप्लाई चेन से संबंधित प्रक्रियाओं पर एक सामान्य नजर डालनी चाहिए।
आखिरकार, Log4Shell, भले ही सुरक्षा-प्रासंगिक अंतर कितना ही क्यों न हो, सॉफ़्टवेयर आपूर्ति श्रृंखला में "केवल" एक दोषपूर्ण घटक है," ट्रेंड माइक्रो में IoT सुरक्षा प्रचारक यूरोप, उडो श्नाइडर कहते हैं।
Log4Shell - क्या आप अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला के बारे में जानते हैं?
बेशक, Log4Shell भेद्यता द्वारा उत्पन्न गंभीर खतरे को तत्काल प्रतिक्रिया की आवश्यकता है। लेकिन दूसरे चरण में, कंपनियों को आम तौर पर सॉफ़्टवेयर आपूर्ति श्रृंखलाओं और प्रलेखित (?) निर्भरताओं से संबंधित प्रक्रियाओं के बारे में स्वयं से प्रश्न पूछने होते हैं।
Log4Shell भेद्यता जो कुछ दिनों पहले ज्ञात हुई थी, हर किसी के होठों पर है और दुनिया भर के सुरक्षा विशेषज्ञों को उनके पैर की उंगलियों पर रखती है। BSI एक "बेहद गंभीर खतरे की स्थिति" की बात करता है क्योंकि असुरक्षित Log4J लाइब्रेरी जावा वातावरण में "लॉग" मानक है। तदनुसार, इसका उपयोग हजारों अनुप्रयोगों और इंटरनेट सेवाओं में भी किया जाता है। इसके अलावा, भेद्यता का दुरुपयोग करना आसान है और कई मामलों में दूरस्थ रूप से शोषण किया जा सकता है, अंततः मनमाना आदेश निष्पादन की अनुमति देता है। साइबर सुरक्षा के दृष्टिकोण से एक वास्तविक दुःस्वप्न! संगठन हमारी विस्तृत सिफारिशों का पालन कर सकते हैं और मौजूदा पैच लागू कर सकते हैं और तत्काल प्रतिक्रिया के लिए सर्वोत्तम अभ्यास लागू कर सकते हैं। लेकिन दूसरे चरण में, उन्हें सॉफ्टवेयर सप्लाई चेन से संबंधित प्रक्रियाओं पर एक सामान्य नजर डालनी चाहिए। आखिरकार, यहां तक कि Log4Shell, चाहे सुरक्षा-प्रासंगिक भेद्यता कितनी भी हो, सॉफ़्टवेयर आपूर्ति श्रृंखला में "केवल" एक दोषपूर्ण घटक है।
Log4Shell दोषपूर्ण बिल्डिंग ब्लॉक
सॉफ्टवेयर आपूर्ति श्रृंखलाओं और उनके संदर्भ को समझने के लिए, यह "वास्तविक" दुनिया को देखने में मदद करता है, जैसे कि इलेक्ट्रॉनिक उत्पादों का निर्माण। विधानसभाओं के लिए तथाकथित "बिल ऑफ मटेरियल" (बीओएम - बिल ऑफ मैटेरियल) आम बात है। यदि आप एक एकल सर्किट बोर्ड को एक असेंबली के रूप में देखते हैं, तो उपयुक्त भागों की सूची में उपयोग किए जाने वाले सभी घटकों की सूची होती है, जैसे प्रतिरोधक, कैपेसिटर, डायोड, आईसी और बहुत कुछ। प्रत्येक घटक के लिए सटीक पैरामीटर, निर्माता, मूल्य, आपूर्ति के स्रोत और अंततः सीरियल नंबर या कम से कम बैच जानकारी भी संग्रहीत की जाती है।
यदि घटकों में से किसी एक के निर्माता से जानकारी है कि बैच के कुछ घटक निर्दिष्ट तापमान मानों के अनुरूप नहीं हैं, तो यह पता लगाना संभव है कि कौन से बोर्ड (प्रत्येक अपने स्वयं के सीरियल नंबर के साथ) प्रभावित हैं और बी ) क्या कार्रवाई की आवश्यकता है। यदि उचित उपाय शुरू किए जाने हैं, तो जानकारी कि कौन सी विधानसभाएं प्रभावित होती हैं (क्रम संख्या के आधार पर) निश्चित रूप से बहुत मदद करती हैं। आखिरकार, यह प्रक्रिया "असेंबली" के साथ लगभग अपनी मर्जी से जारी रहती है ... जब तक कि आप अंततः CERN में LHC जैसे बड़े इंस्टॉलेशन के साथ समाप्त नहीं हो जाते। इतनी बड़ी मशीन के साथ भी, एक छोटे एसएमडी घटक की विफलता से पूरी मशीन विफल हो सकती है। यदि, उदाहरण के लिए, दोषपूर्ण बैच ज्ञात हो जाते हैं, तो अंततः आपको स्थापित प्रत्येक अलग-अलग प्रतिरोधी को सत्यापित करने में सक्षम होना चाहिए।
सामग्री का सॉफ्टवेयर बिल (एसबीओएम)
ठीक इसी तरह से सॉफ्टवेयर सप्लाई चेन काम करती है, यानी SBOMs” — और विशेष रूप से Log4Shell पर वापस: क्या आप जल्दी से कह सकते हैं कि क्या आप इस अंतर से प्रभावित हैं? आपके अपने सॉफ़्टवेयर के साथ जो Log4J का उपयोग करता है, प्रश्न का उत्तर शायद शीघ्रता से दिया जा सकता है। अक्सर GitHub या GitLab जैसी SCM सेवाएं भी सीधे ऐसे कार्यों की पेशकश करती हैं। लेकिन क्षणिक निर्भरताओं के बारे में क्या? क्या आपके द्वारा उपयोग की जाने वाली तृतीय-पक्ष लाइब्रेरी आंतरिक रूप से Log4J का उपयोग करती है? या इससे भी बदतर - क्या आपके द्वारा उपयोग की जाने वाली लाइब्रेरी एक लाइब्रेरी का उपयोग करती है जो बदले में (आदि) एक लाइब्रेरी पर निर्भर करती है जो Log4J का उपयोग करती है? क्या सर्विस प्रोवाइडर का खरीदा हुआ सॉफ्टवेयर Log4J पर निर्भर करता है? क्या आपके द्वारा खरीदी गई क्लाउड सेवा Log4J का उपयोग करती है?
एसबीओएम सामग्री (छवि: ट्रेंड माइक्रो)।
प्रश्नों पर प्रश्न जिनके उत्तर की आवश्यकता है जिनके लिए आपको एसबीओएम से जूझना पड़ता है। Log4Shell स्पष्ट रूप से उन समस्याओं को दिखाता है जो तब उत्पन्न होती हैं जब सॉफ़्टवेयर आपूर्ति श्रृंखला का दस्तावेजीकरण नहीं किया जाता है। लेकिन मूर्ख मत बनो। Log4Shell निश्चित रूप से इस समय सबसे खराब स्थिति है। लेकिन सरल "दोषों" के साथ भी जो सुरक्षा के लिए सीधे प्रासंगिक नहीं हैं, यह सवाल कि क्या आप प्रभावित हैं, महत्वपूर्ण है!
दस्तावेज़ निर्भरताएँ
मूल रूप से, एसबीओएम दस्तावेज़ीकरण निर्भरताओं के बारे में हैं। ये सॉफ्टवेयर (घटक) के रूप में निर्भरता हो सकते हैं, लेकिन सेवाओं, लाइसेंस, सर्वर और भी बहुत कुछ। खासकर जब मॉडलिंग सॉफ्टवेयर निर्भरता की बात आती है, तो समय के साथ दो विनिमय प्रारूप सामने आए हैं: साइक्लोनडीएक्स और एसपीडीएक्स। दोनों संभावित निर्भरताओं सहित विभिन्न सॉफ़्टवेयर घटकों के विवरण की अनुमति देते हैं:
लेकिन वर्णनात्मक भाषा पर्याप्त नहीं है। बल्कि, विशिष्ट परिवेश का भी वर्णन किया जाना चाहिए और उसे अद्यतन रखा जाना चाहिए। बेशक, ये विवरण मैन्युअल रूप से बनाए जा सकते हैं - और कभी-कभी, उदाहरण के लिए जब बाहरी सेवाओं पर निर्भर होते हैं, तो कोई अन्य विकल्प नहीं होता है। हालाँकि, जब सॉफ़्टवेयर के लिए विवरण बनाने की बात आती है, तो मैन्युअल प्रयास का कोई मतलब नहीं होता है। यहां, CI/CD पाइपलाइन के हिस्से के रूप में इन विवरणों का निर्माण और रखरखाव पूरी तरह से स्वचालित रूप से होना चाहिए। मूल रूप से दो दृष्टिकोण हैं: निर्माण प्रक्रिया में एकीकरण और निर्माण कलाकृतियों की स्कैनिंग।
सीआई/सीडी एकीकरण - निर्माण प्रक्रिया
निर्माण प्रक्रिया के दौरान एसबीओएम निर्माण (छवि: ट्रेंड माइक्रो)।
CycloneDX और SPDX दोनों में ऐसे उपकरण हैं जिन्हें सीधे निर्माण प्रक्रिया में एकीकृत किया जा सकता है। ये सीधे "स्रोत पर" (क्षणिक) निर्भरताओं को निकालते हैं। ये पुस्तकालय, निष्पादन योग्य फाइलें, लेकिन कंटेनर या कंटेनर परतें भी हो सकती हैं। प्रत्यक्ष एकीकरण भी मौजूद निर्भरता को ट्रैक करना संभव बनाता है, उदाहरण के लिए, केवल निर्माण के दौरान, लेकिन तैयार उत्पाद में नहीं।
सीआई/सीडी एकीकरण - आर्टिफैक्ट बनाएं
यहां तक कि अगर आपको निर्माण प्रक्रिया में सीधे हस्तक्षेप करने की अनुमति नहीं है, तो साइक्लोनडीएक्स और एसपीडीएक्स के लिए उपकरण हैं जो "बाद में" अंतिम परिणाम को स्कैन करते हैं। इसका मतलब यह है कि ये उपकरण जावा एप्लिकेशन से निर्भरता निकालते हैं, उदाहरण के लिए, और उन्हें प्रलेखित करते हैं। चूंकि ये उपकरण हमेशा केवल अंतिम परिणाम देखते हैं, यह बहुत संभव है कि कुछ निर्भरताओं को आसानी से अनदेखा कर दिया जाए, क्योंकि उन्हें अब अंतिम परिणाम से नहीं निकाला जा सकता है।
भेद्यता निगरानी
निर्माण प्रक्रिया के बाद एसबीओएम निर्माण (छवि: ट्रेंड माइक्रो)।
केवल भेद्यता निगरानी में रुचि रखने वाली कंपनियों के लिए, इनमें से कई उपकरण भेद्यता डेटाबेस के साथ सीधा संबंध भी प्रदान करते हैं। इसका मतलब यह है कि आउटपुट में न केवल पाए गए घटक होते हैं, बल्कि कमजोरियों की एक सूची भी होती है। यह तुलनीय है, उदाहरण के लिए, CI / CD पाइपलाइन में snyk, Trend माइक्रो एप्लिकेशन सिक्योरिटी या ट्रेंड माइक्रो कंटेनर सिक्योरिटी के एकीकरण के लिए।
OWASP डिपेंडेंसी ट्रैक
यदि लाइसेंस, सूची या वितरण की डिग्री की ट्रैकिंग और दस्तावेज़ीकरण भी एक भूमिका निभाते हैं, तो अन्य समाधान (अतिरिक्त रूप से) उपलब्ध हैं। इस वातावरण में, OWASP (ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट) का डिपेंडेंसी ट्रैक टूल निश्चित रूप से शीर्ष कुत्तों में से एक है। ओपन सोर्स समाधान के रूप में, यह आमतौर पर सीआई/सीडी पाइपलाइनों में एकीकृत होता है और वहां एसबीओएम डेटा प्राप्त करता है - या तो साइक्लोनडीएक्स/एसपीडीएक्स डेटा (मैनुअल, एपीआई) या सीधे निर्माण प्रक्रिया से। इसके अलावा, डिपेंडेंसी ट्रैक स्वचालित रूप से विभिन्न भेद्यता डेटाबेस से भेद्यता डेटा संग्रहीत करता है और डेटा को (ऐतिहासिक) बिल्ड और कमजोरियों से लगातार संबद्ध करता है। मैच तदनुसार डैशबोर्ड में प्रदर्शित किए जाते हैं या सीधे चैट और सीआई/सीडी एकीकरण के माध्यम से रिपोर्ट किए जाते हैं या वैकल्पिक रूप से स्वचालित सुधार के लिए टूल को अग्रेषित किए जाते हैं।
निर्भरता ट्रैक एकीकरण (छवि: https://github.com/DependencyTrack/dependency-track )
निर्भरता ट्रैक एक डेटाबेस है जिसके साथ प्रश्न: "मैं Log4Shell से कहां प्रभावित हूं" का उत्तर आसानी से दिया जा सकता है। इस उत्तर में न केवल सॉफ़्टवेयर के वर्तमान संस्करण शामिल हैं, बल्कि पुराने संस्करणों का विवरण भी दिया गया है। एक संभावित खोज इसलिए हो सकती है कि एक कंपनी वर्तमान संस्करण में प्रभावित नहीं है (चूंकि यह पर्याप्त रूप से पैच किया गया है), लेकिन 34 पुराने संस्करण प्रभावित हैं। यदि आप अब भी स्थापित संस्करणों की संख्या के बारे में जानकारी ट्रैक करते हैं, तो यह एक अच्छी तरह से स्थापित जोखिम मूल्यांकन के लिए लगभग सही डेटा है।
Log4j, Log4Shell और आपूर्ति श्रृंखला पर निष्कर्ष
अंत में, शुरुआत में पूछे गए प्रश्नों का उत्तर देने में सक्षम होना महत्वपूर्ण है: क्या हम (सीधे या हमारी सॉफ़्टवेयर आपूर्ति श्रृंखला में) Log4J का उपयोग करते हैं? यदि हां, तो हम किस हद तक (संस्करण, वितरण) Log4Shell से प्रभावित हैं? इस प्रश्न का उत्तर देने के लिए आवश्यक प्रयास इस बात का सूचक है कि आपको अपनी सॉफ़्टवेयर आपूर्ति श्रृंखला में किस हद तक अंतर्दृष्टि है और क्या यह वहाँ मदद करने के लिए उपकरणों का उपयोग करने के लायक है।
उपकरणों के संबंध में, यह स्पष्ट करना महत्वपूर्ण है कि क्या यह "केवल" प्रश्न "क्या मैं प्रभावित हूं" के बारे में है। यदि यह स्थिति है, तो snyk जैसे उपकरण या GitHub और GitLab में एकीकृत विकल्प मदद करेंगे। दूसरी ओर, यदि एक अधिक व्यापक दृष्टिकोण वांछित है, तो सॉफ्टवेयर कलाकृतियों को पकड़ने और सूचीबद्ध करने के लिए अन्य समाधान हैं। ये कमर्शियल और फ्री दोनों हैं। ओपन सोर्स कैंप से, डिपेंडेंसी ट्रैक निश्चित रूप से यहां सबसे व्यापक है।
अंततः, हालांकि, यह ध्यान दिया जाना चाहिए कि सुरक्षा अंतराल सॉफ्टवेयर आपूर्ति श्रृंखला प्रबंधन के लिए एक महत्वपूर्ण तर्क है - लेकिन निश्चित रूप से केवल एक ही नहीं है!
TrendMicro.com पर अधिक
ट्रेंड माइक्रो के बारे में आईटी सुरक्षा के दुनिया के अग्रणी प्रदाताओं में से एक के रूप में, ट्रेंड माइक्रो डिजिटल डेटा एक्सचेंज के लिए एक सुरक्षित दुनिया बनाने में मदद करता है। 30 से अधिक वर्षों की सुरक्षा विशेषज्ञता, वैश्विक खतरा अनुसंधान और निरंतर नवाचार के साथ, ट्रेंड माइक्रो व्यवसायों, सरकारी एजेंसियों और उपभोक्ताओं के लिए सुरक्षा प्रदान करता है। हमारी XGen™ सुरक्षा रणनीति के लिए धन्यवाद, हमारे समाधान अग्रणी-एज वातावरण के लिए अनुकूलित रक्षा तकनीकों के एक क्रॉस-जेनरेशनल संयोजन से लाभान्वित होते हैं। नेटवर्क की खतरे की जानकारी बेहतर और तेज सुरक्षा को सक्षम बनाती है। क्लाउड वर्कलोड, एंडपॉइंट्स, ईमेल, IIoT और नेटवर्क के लिए अनुकूलित, हमारे कनेक्टेड समाधान तेजी से खतरे का पता लगाने और प्रतिक्रिया के लिए पूरे उद्यम में केंद्रीकृत दृश्यता प्रदान करते हैं।