नई कमजोरियों के उजागर होने की दर लगातार बढ़ रही है। वर्तमान में यह प्रति वर्ष औसतन 15,000 सीवीई है। 2022 में 26,000 से अधिक नए सीवीई की सूचना दी गई है। जाहिर है, सभी कमजोरियाँ आपके सॉफ़्टवेयर के लिए प्रासंगिक नहीं हैं। यह पता लगाने के लिए कि क्या कोई विशेष भेद्यता एक समस्या है, आपको पहले यह पता लगाना होगा कि क्या आप उस लाइब्रेरी या उत्पाद का उपयोग कर रहे हैं जिसमें भेद्यता है, फिर पता लगाएं कि क्या आप उस लाइब्रेरी के समस्याग्रस्त संस्करण और मॉड्यूल का उपयोग कर रहे हैं। अंत में, आपको यह देखने के लिए अपनी विकास टीम से परामर्श करने की आवश्यकता है कि क्या वह भेद्यता आपके विशेष उत्पाद के लिए प्रासंगिक है और जिस तरह से आपने उस असुरक्षित लाइब्रेरी या उत्पाद का उपयोग किया है।
यह सब पता लगाने की प्रक्रिया सरल नहीं है और इसमें काफी समय लग सकता है। जाने-माने साइबर सुरक्षा विशेषज्ञ टॉम एलरिच का अनुमान है किसी विशेष सॉफ़्टवेयर उत्पाद में मौजूद सभी सीवीई में से लगभग 95% शोषण योग्य नहीं हैं. लेकिन, यदि आप एक अंतिम उपयोगकर्ता हैं या कोई कंपनी अपने सिस्टम में तृतीय-पक्ष सॉफ़्टवेयर को एकीकृत करने वाली है, तो आप समस्याग्रस्त 5% की पहचान कैसे कर सकते हैं ताकि आप उचित उपचार या पैचिंग के लिए पूछ सकें?
यहीं का विचार है वल्नरेबिलिटी एक्सप्लॉइटेबिलिटी एक्सचेंज (वीईएक्स) आता है. VEX का उद्देश्य, जैसा कि परिभाषित किया गया है मार्गदर्शन 2021 में यूएस नेशनल टेलीकम्युनिकेशंस एंड इंफॉर्मेशन एडमिनिस्ट्रेशन (एनटीआईए) से, "उपयोगकर्ताओं (जैसे, ऑपरेटरों, डेवलपर्स और सेवा प्रदाताओं) को अतिरिक्त जानकारी प्रदान करना है कि क्या कोई उत्पाद शामिल घटक में एक विशिष्ट भेद्यता से प्रभावित होता है और यदि प्रभावित होता है , क्या समाधान के लिए कार्रवाई की सिफारिश की गई है।"
अभी आप शायद सोच रहे हैं - तो मैं ये VEX दस्तावेज़ कैसे प्राप्त कर सकता हूँ, और अपने घटकों की जाँच कैसे शुरू कर सकता हूँ? खैर, VEX के उपयोग की वास्तविकता, हमेशा की तरह, जटिल है।
VEX के उद्देश्य की खोज करें
सीधे शब्दों में कहें तो, VEX को इस प्रश्न का त्वरित और आसानी से उत्तर देना चाहिए कि 'क्या इस सॉफ़्टवेयर का मेरा संस्करण इसके लिए उपयोगी है भेद्यता?'.
उस प्रश्न का उत्तर चार प्रमुख विकल्पों में से एक माना जाता है:
- प्रभावित नहीं: इस भेद्यता के संबंध में किसी उपचार की आवश्यकता नहीं है।
- प्रभावित: इस भेद्यता को सुधारने या संबोधित करने के लिए कार्रवाई की अनुशंसा की जाती है।
- फिक्स्ड: इन उत्पाद संस्करणों में भेद्यता का समाधान शामिल है।
- जांच के तहत: यह अभी तक ज्ञात नहीं है कि ये उत्पाद संस्करण भेद्यता से प्रभावित हैं या नहीं। एक अद्यतन बाद की रिलीज़ में प्रदान किया जाएगा।
चूँकि VEX को मशीन-पठनीय और मशीन-जनरेटेड दोनों माना जाता है, इसलिए विचार यह है कि इन दस्तावेज़ों का एक खोजने योग्य डेटाबेस कहीं हो ताकि कोई भी इच्छुक पक्ष इससे पूछताछ कर सके और आवश्यक उत्तर प्राप्त कर सके।
चूँकि धारणा यह है कि किसी भी सॉफ्टवेयर उत्पाद में 95% कमजोरियाँ शोषण योग्य नहीं हैं, इस प्रणाली का उद्देश्य प्रत्येक उत्पाद के लिए पाई जाने वाली कमजोरियों की विशाल सूची को केवल उन तक सीमित करना है जिन पर उपयोगकर्ता को नजर रखनी चाहिए या सुधार या पैचिंग का अनुरोध करना चाहिए। के लिए।
VEX के इतिहास के बारे में कई दिलचस्प तथ्य हैं
2020 में वापस, एनटीआईए (अमेरिकी राष्ट्रीय दूरसंचार और सूचना प्रशासन) ने एक सहायक उपकरण के रूप में VEX के विचार पर चर्चा शुरू की एसबीएम (सामग्री का सॉफ्टवेयर बिल)। सितंबर 2021 में, एनटीआईए ने एक पेज का परिचय और स्पष्टीकरण जारी किया कि VEX को क्या करना चाहिए।
बाद में, नए सलाहकार प्रारूप की आवश्यकताओं को परिष्कृत करने का प्रयास सीआईएसए - यूएस साइबर सिक्योरिटी एंड इंफ्रास्ट्रक्चर सिक्योरिटी एजेंसी के तत्वावधान में किया गया, जिसने अपना स्वयं का संस्करण जारी किया दस्तावेज़ 2022 की शुरुआत में थोड़ा और विस्तार के साथ-साथ कुछ उपयोग के मामलों पर भी विचार किया जाएगा, जिसमें VEX दस्तावेज़ को मदद मिलनी चाहिए थी। दस्तावेज़, एक मसौदा, VEX दस्तावेज़ के न्यूनतम आवश्यक फ़ील्ड को उसी तरह परिभाषित करता है जैसे NTIA ने SBOM के न्यूनतम आवश्यक फ़ील्ड को परिभाषित किया है।
तब से वास्तव में मशीन-पठनीय VEX दस्तावेज़ीकरण प्रारूप बनाने के 2 प्रमुख प्रयास हुए:
- RSI सामान्य सुरक्षा सलाहकार ढांचा (सीएसएएफ) पहला प्रारूप उपलब्ध था। यह प्रारूप 2022 के अंत में OASIS ओपन द्वारा जारी किया गया था, जो साइबर सुरक्षा, ब्लॉकचेन, IoT और अन्य क्षेत्रों के लिए ओपन-सोर्स मानकों के निर्माण के लिए समर्पित एक अंतरराष्ट्रीय गैर-लाभकारी संस्था है।
- चक्रवात डीएक्स, OWASP (ओपन वेब एप्लिकेशन सिक्योरिटी प्रोजेक्ट) द्वारा लॉन्च किए गए SBOMs के लिए एक मानकीकृत प्रारूप, जिसे VEX दस्तावेज़ बनाने के लिए भी अनुकूलित किया गया था।
सीएसएएफ एक व्यापक प्रारूप है, लेकिन वास्तव में इसका सफलतापूर्वक उपयोग करने के लिए आपको कई क्षेत्रों और बहुत सारी मेटा जानकारी को शामिल करने की आवश्यकता है, जिससे वास्तविक गोद लेने की संभावना कम हो जाती है। साइक्लोनडीएक्स वीईएक्स पहल बहुत पतली है, इसलिए जब इस बात पर विचार किया जाएगा कि किस वीईएक्स मानक का सबसे अधिक उपयोग किया जाना चाहिए CyclonDX प्रारूप के साथ।
VEX की राह में रुकावट क्यों आई - इसकी सफलता में बाधा डालने वाले मुद्दों को उजागर करना
VEX एक अच्छा विचार है और यह तुरंत जांचने की मूल्यवान क्षमता प्रदान कर सकता है कि क्या किसी विशेष सॉफ्टवेयर उत्पाद में कोई विशेष भेद्यता वास्तव में शोषण योग्य है।
हालाँकि, कई समस्याएँ हैं, जो अब तक इसके कार्यान्वयन में बाधा बन रही हैं:
- दाखिल करने की ज़िम्मेदारी - आवश्यक वीईएक्स दस्तावेज़ दाखिल करने का प्रभारी कौन होना चाहिए? क्या यह सॉफ्टवेयर निर्माता हैं? तृतीय-पक्ष सुरक्षा कंपनियाँ या गैर-लाभकारी संगठन? एक सरकारी एजेंसी? यदि एकाधिक स्रोत विरोधाभासी जानकारी दर्ज करें तो क्या होगा?
- VEX डेटाबेस - VEX जानकारी को किसे या किसे सहेजना और वर्गीकृत करना चाहिए? यह मानते हुए कि कुछ दस्तावेज़ सॉफ़्टवेयर में शोषक मुद्दों का वर्णन करेंगे, क्या यह ख़तरा नहीं है कि जानकारी गलत (दुर्भावनापूर्ण) हाथों में पड़ जाएगी?
- वर्तमान प्रारूप संस्करणों के प्रश्न को ठीक से कवर नहीं करते हैं और संयुक्त संस्करण की समस्या को तो और भी कम कवर करते हैं।
संयुक्त सॉफ्टवेयर/पैकेज संस्करण कई सॉफ्टवेयर पैकेजों या घटकों को एक रिलीज या इंस्टॉलेशन पैकेज में एक साथ बंडल करने की प्रथा को संदर्भित करता है।
जब भेद्यता पैचिंग की बात आती है, तो संयुक्त सॉफ़्टवेयर/पैकेज संस्करण इस प्रक्रिया में मदद भी कर सकते हैं और बाधा भी डाल सकते हैं। एक ओर, एक एकल इंस्टॉलेशन पैकेज जिसमें सभी आवश्यक घटक शामिल हैं, कमजोरियों की पहचान करने और उन्हें ठीक करने की प्रक्रिया को सरल बना सकता है। प्रत्येक व्यक्तिगत घटक को मैन्युअल रूप से पहचानने और पैच करने की आवश्यकता के बजाय, आप पैच को पूरे पैकेज पर आसानी से लागू कर सकते हैं।
हालाँकि, इसका दूसरा पक्ष यह है कि यदि पैकेज के भीतर एक घटक असुरक्षित है, तो पूरा सॉफ्टवेयर असुरक्षित है। इसका मतलब यह है कि भले ही पैकेज के भीतर कुछ घटकों को पैच कर दिया गया हो, एक भी अनपैच्ड घटक मौजूद होने पर समग्र पैकेज अभी भी जोखिम में हो सकता है।
मान लीजिए कि आपके सॉफ़्टवेयर में लाइब्रेरी ए के संस्करण 1 में भेद्यता है। यह समस्या केवल तभी प्रकट होती है जब लाइब्रेरी ए लाइब्रेरी बी के संस्करण 2 के साथ मौजूद होती है। एक सुरक्षा पैच है लेकिन हर किसी ने इसे स्थापित नहीं किया होगा। इसका मतलब है कि आपके सॉफ़्टवेयर में उस भेद्यता के लिए VEX दस्तावेज़ में उत्पाद के सभी संभावित संयोजनों, उसके संस्करणों, उसमें निहित पुस्तकालयों, उनके संस्करणों और जारी किए गए संभावित पैच को शामिल करने की आवश्यकता है। यह बहुत सारी जटिल जानकारी है जिसे आसानी से व्यक्त करना आसान नहीं है।
- VEX उस सॉफ़्टवेयर को कैसे कवर करेगा जो हार्डवेयर में उपलब्ध सभी संभावित संस्करणों और पैच के साथ एम्बेडेड है? इस सॉफ़्टवेयर को पैच करने की ज़िम्मेदारी किसकी होगी, यह देखते हुए कि आप हार्डवेयर को आसानी से नहीं खोल सकते हैं और चीज़ों को स्वयं पैच नहीं कर सकते हैं?
ये केवल कुछ समस्याएं हैं जिन्हें VEX से निपटने के लिए किसी भी स्वचालित टूलींग को समझने और ध्यान में रखने की आवश्यकता होगी।
क्या यह आसान नहीं होगा यदि आप किसी भी संस्करण के लिए अनुरोध कर सकें और जानकारी प्राप्त कर सकें?
यह धारणा कि इस महत्वपूर्ण जानकारी को साझा करने का सबसे अच्छा तरीका एक दस्तावेज़ है, संभवतः ग़लत है। संस्करण, पैच और भेद्यता के हर संयोजन को कवर करने के लिए पर्याप्त VEX दस्तावेज़ बनाना एक महत्वपूर्ण कार्य है, जिसे, जाहिर है, कोई भी नहीं करना चाहता है।
मुंशी किसी विशेष सॉफ़्टवेयर प्रोजेक्ट या उत्पाद के प्रत्येक निर्माण के लिए सुरक्षा-संबंधी जानकारी को ट्रैक करने और साझा करने के लिए एक प्लेटफ़ॉर्म बनाया है। इसके भाग के रूप में, प्रत्येक बिल्ड एक सटीक एसबीओएम और उत्पाद में खोजी गई कमजोरियों की एक सूची तैयार करता है।
स्क्राइब सॉफ्टवेयर निर्माता को इन कमजोरियों में से प्रत्येक के लिए VEX प्रारूप में सलाह जोड़ने में सक्षम बनाता है ताकि यह नोट किया जा सके कि क्या वे शोषण योग्य नहीं हैं, जांच के अधीन हैं, आदि। एक बार एक संस्करण जारी होने के बाद उस संस्करण के बारे में सभी सुरक्षा जानकारी इच्छुक तीसरे पक्षों, उपयोगकर्ताओं के साथ साझा की जा सकती है। , नियामक, इत्यादि। भेद्यता सूची के साथ-साथ वीईएक्स सलाहकार सूची को शामिल करने का मतलब है कि प्राप्तकर्ता को केवल उन कमजोरियों को देखने में सक्षम होना चाहिए जो इस विशेष उत्पाद में एक संभावित समस्या हैं। यह सॉफ़्टवेयर निर्माता, जो अपने उत्पाद को "श्वेतसूची" में डाल सकता है, और सॉफ़्टवेयर उपभोक्ता, जो यह समझता है कि किसी विशिष्ट सॉफ़्टवेयर उत्पाद में किस स्तर का जोखिम शामिल है, दोनों का बहुत सारा बोझ हटा देता है।
चूंकि सॉफ़्टवेयर निर्माता ही एकमात्र ऐसा व्यक्ति है जो निश्चित रूप से कह सकता है कि क्या कोई विशेष भेद्यता, वास्तव में, उत्पाद के किसी विशेष संस्करण के लिए प्रासंगिक है, वे एकमात्र ऐसे व्यक्ति हैं जो अपने स्वयं के उत्पादों पर सलाह जोड़ और संशोधित कर सकते हैं। इस संबंध में सॉफ़्टवेयर निर्माता का निर्णय अंतिम और गैर-प्रतिवादात्मक है। यह जानकारी किसके साथ साझा करनी है इसका निर्णय भी सॉफ्टवेयर निर्माता का विशेषाधिकार है।
चूंकि उत्पाद के निर्माण, एसबीओएम और सुरक्षा जानकारी का पूरा इतिहास स्क्राइब द्वारा सहेजा जाता है, उपयोगकर्ता आसानी से अनुरोध कर सकते हैं और पूरे सॉफ़्टवेयर जीवन चक्र के दौरान उपयोग किए जा रहे किसी भी संस्करण के लिए यह जानकारी प्राप्त कर सकते हैं।
निष्कर्ष
याद रखें कि इन दिनों किसी सॉफ़्टवेयर उत्पाद का कोई भी अच्छा स्कैन सैकड़ों नहीं तो हज़ारों संभावित कमज़ोरियाँ उत्पन्न करेगा। अधिकांश लोग इतनी संख्या से निपट नहीं सकते। सतर्क थकान शुरू हो जाती है और कमजोरियों की संख्या बस उतनी ही हो जाती है - एक संख्या।
पहचानी गई समस्याओं की संख्या को प्रबंधनीय मात्रा तक कम करने की संभावना सॉफ्टवेयर उत्पादकों और उपयोगकर्ताओं के लिए एक वरदान होगी। इसका उद्देश्य केवल वास्तविक समस्याओं पर ध्यान केंद्रित करना है ताकि सॉफ्टवेयर निर्माता उन्हें जल्द से जल्द ठीक करने और उनका समाधान करने में सक्षम हो सके।
स्वचालित उपकरण, जैसे मुंशी आपके प्रत्येक प्रोजेक्ट और निर्माण के लिए केवल प्रासंगिक कमजोरियों को देखने का एक आसान तरीका प्रदान करता है, जानकारी जिसे आप आसानी से साझा कर सकते हैं, जिससे कमजोरियों का पहाड़ काफी छोटा हो जाता है और अधिक प्रबंधनीय हो जाता है।
हालांकि एक महत्वपूर्ण चेतावनी यह है कि यह भविष्य, जहां हम केवल प्रासंगिक कमजोरियों को आसानी से देख सकते हैं और उन पर प्रतिक्रिया दे सकते हैं, ओपन-सोर्स समुदाय की सक्रिय भागीदारी के बिना संभव नहीं होगा। इन दिनों अधिकांश कोड में बड़ी मात्रा में ओपन-सोर्स सॉफ़्टवेयर शामिल होते हैं, इसलिए हमें ऐसे पुस्तकालयों के अनुरक्षकों और डेवलपर्स की आवश्यकता होती है जो उनके कोड को प्रभावित करने वाली शोषक कमजोरियों की खोज और निवारण में भाग लेते हैं।
प्रासंगिक, शोषण योग्य कमजोरियों की समस्या दूर नहीं हो रही है, इसलिए यह हम सभी के लिए आवश्यक है कि हम इस प्रश्न का उत्तर पाने के लिए सबसे कुशल, लागत प्रभावी तरीका खोजें: 'क्या इस सॉफ़्टवेयर का मेरा संस्करण इसके लिए शोषण योग्य है? भेद्यता'.
यह सामग्री आपके लिए स्क्राइब सिक्योरिटी द्वारा लाई गई है, जो एक अग्रणी एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा समाधान प्रदाता है - जो संपूर्ण सॉफ्टवेयर आपूर्ति श्रृंखलाओं में कोड कलाकृतियों और कोड विकास और वितरण प्रक्रियाओं के लिए अत्याधुनिक सुरक्षा प्रदान करता है। और अधिक जानें.
संबंधित पोस्ट
