भेद्यता स्कैन में सीवीई बर्नआउट और अलर्ट थकान से कैसे बचें?

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

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

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

आइए सबसे पहले यह देखें कि सीवीई की पहचान कैसे की जाती है।

द मिस्ट्री पैकेज और मिसिंग सीवीई 

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

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

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

क्या आप मेरी माँ हैं?

डॉकर छवि के अंतिम निर्माण के साथ काम करते समय, इन दिनों शुरुआत से शुरुआत न करना आम बात है। एक ठोस प्रारंभिक बिंदु होने से, जैसे कि एक स्थापित आधार छवि, डेवलपर्स को उस वातावरण की योजना बनाना शुरू करने के बजाय निर्माण के उस हिस्से पर ध्यान केंद्रित करने की अनुमति देती है जो उनका अनुप्रयोग है जिस पर इसे चलाने की आवश्यकता होती है। डॉकर छवियों का उपयोग करने में चुनौतियों में से एक उनकी उत्पत्ति और निर्भरता को समझना है, खासकर जब मूल छवि (आधार छवि के अलावा) की बात आती है जिसके ऊपर अंतिम छवि बनाई जाती है।

मूल छवि एक अवधारणा है जिसके बारे में हमने डॉकर छवि के निकटतम 'जीवित रिश्तेदार' को समझाने के लिए सोचा था। छवियां अलग-अलग परतों में बनाई जाती हैं, इसलिए, मान लें कि मैं अल्पाइन, डेबियन या उबंटू जैसी ज्ञात आधार छवि का उपयोग करता हूं, और इसके ठीक ऊपर अपनी एप्लिकेशन परत बनाता हूं। इस मामले में, मेरी निकटतम 'माता-पिता' वह आधार छवि होगी। लेकिन क्या होगा अगर मैं जिस कंपनी के लिए काम करता हूं उसका शुरुआती बिंदु अलग हो, जिसमें एक आधार छवि और सुरक्षा उपकरणों के शीर्ष पर कुछ और परतें शामिल हों जो सभी कंपनी छवियों के लिए अनिवार्य हैं? इस मामले में, मेरी मूल छवि यह कंपनी टेम्पलेट होगी और मैं उस आधार छवि की पहचान करने में भी सक्षम होऊंगा जिस पर यह टेम्पलेट बनाया गया था। 

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

इस समस्या के समाधान के लिए, स्क्राइब ने एक ओपन-सोर्स टूल और सेवा विकसित की जिसका नाम है पेरेंटइमेज डॉकर छवि के निकटतम स्कैन किए गए पैरेंट का पता लगाने के लिए। इस उपकरण का उपयोग डॉकर छवि की मूल छवि की पहचान करने के लिए किया जा सकता है, जो एक प्रमुख जोखिम-घटाने वाला प्रवर्तक है:

सबसे पहले, आधार छवि की पहचान करके, कोई इसकी अखंडता को सत्यापित कर सकता है और यह सुनिश्चित कर सकता है कि इसके साथ छेड़छाड़ या समझौता नहीं किया गया है। यह एप्लिकेशन की सुरक्षा और स्थिरता बनाए रखने के लिए महत्वपूर्ण है।

दूसरा, यह समझकर कि कौन सी कमजोरियाँ मूल छवि से उत्पन्न होती हैं और कौन सी एप्लिकेशन परत से उत्पन्न होती हैं, कोई भी कमजोरियों को अधिक प्रभावी ढंग से प्राथमिकता दे सकता है और प्रबंधित कर सकता है। इसका मतलब यह है कि सीवीई जो आपकी मूल छवि या आपकी मूल छवि से जुड़े हुए हैं, एप्लिकेशन परत में सीवीई की तुलना में कम जरूरी हैं (और हमेशा आपकी जिम्मेदारी नहीं है)।

इसके अतिरिक्त, मूल छवि की पहचान करके, कोई इसके लाइसेंस को सत्यापित कर सकता है और कानूनी और आंतरिक-नीति आवश्यकताओं का अनुपालन सुनिश्चित कर सकता है।

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

क्या मुझे स्कैन करना चाहिए या छोड़ देना चाहिए?

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

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

संख्या जो भी हो, आपको अभी भी अपने सीवीई को संबोधित करने की आवश्यकता है

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

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

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

यदि आपके पास समस्या से निपटने के लिए अन्य ओपन-सोर्स या मुफ़्त टूल हैं तो हमें इसके बारे में सुनना अच्छा लगेगा। इसके बारे में हमें टिप्पणियों में बताएं और समुदाय के साथ साझा करें कि आप अपनी कमजोरियों के पहाड़ से कैसे निपटते हैं। 

संबंधित पोस्ट

क्या आप बिना नक्शे के युद्ध में जाएंगे?

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

एएसपीएम और सीएसपीएम की तुलना: अंतर और अनुप्रयोगों को समझना

यह देखते हुए कि दुनिया अब एक वैश्विक गांव बन गई है, क्लाउड वातावरण और अनुप्रयोगों को सुरक्षित करना अत्यंत महत्वपूर्ण है। संगठनों में इन उद्देश्यों के लिए दो समाधान महत्वपूर्ण हैं, एप्लीकेशन सिक्योरिटी पोस्चर मैनेजमेंट (ASPM) और क्लाउड सिक्योरिटी पोस्चर मैनेजमेंट (CSPM)। प्रत्येक एक सुरक्षा कार्य करता है, हालांकि वे अलग-अलग सेटिंग्स में कार्य करते हैं और […]

अराजकता से स्पष्टता तक: अनुपालन के लिए नीति इंजन को नेविगेट करना

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