नवीनतम ओएमबी मेमो के साथ सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा को अगले स्तर पर ले जाना

सभी पद

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

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

ज्ञापन में राष्ट्र की साइबर सुरक्षा में सुधार, कार्यकारी आदेश (ईओ) 14028 से संबंधित दो मुख्य बिंदु शामिल हैं:

  • ईओ सॉफ्टवेयर आपूर्ति श्रृंखला की सुरक्षा को बढ़ावा देने के उद्देश्य से विकासशील प्रथाओं के लिए मार्गदर्शन साझा करने के लिए राष्ट्रीय मानक और प्रौद्योगिकी संस्थान (एनआईएसटी) को निर्देश देता है। इसे हासिल करने में मदद के लिए, एनआईएसटी ने दो दस्तावेज़ जारी किए: सिक्योर सॉफ्टवेयर डेवलपमेंट फ्रेमवर्क (एसएसडीएफ), एसपी 800-218, तथा सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मार्गदर्शन. साथ में, उन्हें एनआईएसटी मार्गदर्शन कहा जाता है और उन प्रथाओं के एक सेट की रूपरेखा तैयार की जाती है जो सुरक्षित सॉफ़्टवेयर बनाने की नींव बनाते हैं। 
  • ईओ प्रबंधन और बजट कार्यालय को यह भी निर्देश देता है कि एजेंसियों को एनआईएसटी मार्गदर्शन और किसी भी अन्य अपडेट के अनुरूप होने की आवश्यकता शुरू हो। 

स्व-सत्यापन एक शर्त है, लेकिन क्या यही सब कुछ है?

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

आइए बुनियादी बातों से शुरू करें: स्व-सत्यापन वास्तव में क्या है? 

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

ज्ञापन में एक और महत्वपूर्ण बिंदु एजेंसियों के लिए सॉफ्टवेयर कंपनियों को उत्पाद-समावेशी होने के लिए प्रोत्साहित करना है। इससे वे सभी क्रय एजेंसियों को समान सत्यापन प्रदान करने में सक्षम होंगे।

एजेंसी स्व-सत्यापन दस्तावेज़ को तब तक अपने पास रख सकती है जब तक कि सॉफ्टवेयर कंपनी इसे सार्वजनिक रूप से पोस्ट नहीं करती है और अपने प्रस्ताव के भीतर पोस्टिंग के लिए एक लिंक प्रदान नहीं करती है। 

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

यदि सॉफ़्टवेयर कंपनी मानक प्रारूप में स्व-सत्यापन प्रदान नहीं कर पाती है तो क्या होगा?

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

  • उन प्रथाओं की पहचान करें जिन्हें वे प्रमाणित नहीं कर सकते 
  • उन जोखिमों को कम करने के लिए उपयोग में आने वाली सभी प्रथाओं का दस्तावेजीकरण करें 
  • कार्य योजना और मील के पत्थर (POA&M) विकसित करें 

स्वाभाविक रूप से, एजेंसी को यह सुनिश्चित करना होगा कि दस्तावेज़ सार्वजनिक रूप से (विक्रेता या स्वयं एजेंसी द्वारा) पोस्ट नहीं किया जाए।

मान लीजिए कि विक्रेता सभी दस्तावेज़ उपलब्ध कराता है और यह एजेंसी के लिए संतोषजनक है। उस स्थिति में, निर्माता के पास पूर्ण स्व-सत्यापन की कमी के बावजूद बाद वाला सॉफ़्टवेयर उत्पादों या सेवाओं का उपयोग कर सकता है।

स्वीकार्य स्व-सत्यापन में क्या शामिल होना आवश्यक है?

एक स्व-सत्यापन दस्तावेज़ में निम्नलिखित न्यूनतम आवश्यकताएँ शामिल होनी चाहिए: 

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

इस प्रकार का स्व-सत्यापन न्यूनतम आवश्यक स्तर है। फिर भी, यदि एजेंसियां ​​इसके बिना सॉफ्टवेयर खरीदना चाहती हैं - उदाहरण के लिए, इसकी गंभीरता के कारण - तो वे तीसरे पक्ष के मूल्यांकन (में परिभाषित) की मदद से जोखिम-आधारित निर्धारण कर सकती हैं एम 21-30). 

फिर भी, निर्देश एजेंसियों को मानक स्व-सत्यापन फॉर्म का उपयोग करने के लिए प्रोत्साहित करता है। संघीय अधिग्रहण नियामक (एफएआर) परिषद ऐसे मानक और समान स्व-सत्यापन फॉर्म के उपयोग के लिए नियम बनाने का प्रस्ताव करेगी। 

ओपन-सोर्स सॉफ़्टवेयर के लिए स्व-सत्यापन

मान लीजिए कि एजेंसी ओपन-सोर्स सॉफ़्टवेयर या एक सॉफ़्टवेयर उत्पाद प्राप्त करना चाहती है जिसमें ओपन-सोर्स घटक शामिल हों। उस स्थिति में, यह प्रमाणित FedRAMP तृतीय पक्ष मूल्यांकनकर्ता संगठन (3PAO) या स्वयं एजेंसी द्वारा अनुमोदित किसी तृतीय-पक्ष मूल्यांकन की ओर रुख कर सकता है।

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

एसबीओएम एक उद्योग मानक बन रहे हैं। क्या आप इसके लिए तैयार हैं?

मानकों की एक छवि

जबकि स्व-सत्यापन आवश्यक न्यूनतम स्तर है, एजेंसियों को इसकी आवश्यकता नहीं हो सकती है यदि वे जिस उत्पाद या सेवा को प्राप्त करना चाह रहे हैं वह महत्वपूर्ण है और मानक रूप में स्व-सत्यापन प्रदान नहीं कर सकता है।

महत्वपूर्ण बात यह है कि मेमो एजेंसियों को विक्रेताओं से ऐसी कलाकृतियाँ प्राप्त करने के लिए प्रोत्साहित करता है जो सुरक्षित सॉफ्टवेयर विकास प्रथाओं के प्रति उनकी अनुरूपता प्रदर्शित करती हैं। ऐसी ही एक प्रथा में एसबीओएम का होना शामिल है। 

एसबीओएम क्या है और यह कैसे काम करता है?

एसबीओएम सामग्री के सॉफ्टवेयर बिल को संदर्भित करता है, जो सभी घटकों और निर्भरताओं की एक सूची है जो एक सॉफ्टवेयर उत्पाद के विकास और वितरण का हिस्सा हैं।

किसी एजेंसी को इसकी आवश्यकता हो सकती है एसबीएम एजेंसी के लिए सॉफ़्टवेयर की गंभीरता के आधार पर, आग्रह आवश्यकताओं के भाग के रूप में। 

ज्ञापन में एजेंसियों द्वारा एसबीओएम की खरीद और उपयोग के लिए निम्नलिखित दिशानिर्देश शामिल हैं:

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

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

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

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

कंपनियों को अपने सॉफ़्टवेयर उत्पादों में विश्वास बनाने में मदद करने के लिए, हमने हाल ही में एक उपयोग में आसान प्लेटफ़ॉर्म लॉन्च किया है जो एसबीओएम उत्पन्न करने और उन्हें संगठनों के भीतर और पार साझा करने में मदद करता है। कोशिश करो यह देखने के लिए निःशुल्क है कि एसबीओएम उत्पन्न करना, प्रबंधित करना और साझा करना कितना आसान हो सकता है।

यह अब केवल एक सिफ़ारिश नहीं है; अब पालन करने के लिए एक अनिवार्य समयरेखा है

एजेंसियों को इस समयसीमा के अनुरूप मेमो आवश्यकताओं का अनुपालन करना होगा:

  • एजेंसियों के पास है 90 दिन उनके सभी तृतीय-पक्ष सॉफ़्टवेयर की सूची बनाना, जिसमें "महत्वपूर्ण सॉफ़्टवेयर" के लिए एक अलग सूची भी शामिल है। 
  • अंदर 120 दिन, उन्हें "विक्रेताओं को इस ज्ञापन में प्रासंगिक आवश्यकताओं को संप्रेषित करने के लिए एक सुसंगत प्रक्रिया बनाने और यह सुनिश्चित करने की आवश्यकता है कि सॉफ्टवेयर प्रदाताओं द्वारा सार्वजनिक रूप से पोस्ट नहीं किए गए सत्यापन पत्र एक केंद्रीय एजेंसी प्रणाली में एकत्र किए जाएं।" 
  • उनके पास भी है 270 दिन ऐसे सत्यापन पत्र एकत्र करने के लिए जिन्हें "महत्वपूर्ण सॉफ़्टवेयर" के लिए सार्वजनिक रूप से पोस्ट नहीं किया गया है। एक वर्ष के भीतर, एजेंसियों को सभी तृतीय-पक्ष सॉफ़्टवेयर के लिए पत्र एकत्र कर लेने चाहिए।
  • अंत में, भीतर 180 दिन मेमो की तारीख (14 सितंबर, 2022) तक, एजेंसी सीआईओ को किसी भी प्रशिक्षण की आवश्यकता का आकलन करने और सत्यापन दस्तावेजों और कलाकृतियों की समीक्षा और सत्यापन के लिए प्रशिक्षण योजना विकसित करने की आवश्यकता है। 

एजेंसियां ​​बकाया आवश्यकताओं को पूरा करने की योजना के साथ मेमो में बताई गई किसी भी प्रासंगिक समय सीमा से कम से कम 30 दिन पहले विस्तार की मांग कर सकती हैं। छूट का अनुरोध करना भी संभव है, लेकिन केवल असाधारण परिस्थितियों में और सीमित समय सीमा के लिए।

सारांश

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

ऐसा केंद्रीय स्थान किसी दिन स्व-सत्यापन फॉर्म या एसबीओएम से परे विभिन्न प्रकार के सुरक्षा साक्ष्य और सत्यापन के लिए केंद्रीय स्थान बन सकता है। सभी साक्ष्यों को एक ही, साझा करने योग्य स्थान पर रखने से संगठनों को साझा समस्याओं से निपटने में मदद मिलती है, जैसे उभरते नए कारनामे या सीवीई। 

स्क्राइब बिल्कुल इसी बारे में है। पर एक नज़र डालें इस पृष्ठ संगठनों के भीतर और भर में एसबीओएम के निर्माण, प्रबंधन और साझा करने के लिए हमारे व्यापक मंच के बारे में अधिक जानने के लिए। 

बैनर

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