सितंबर 2022 को, यूनाइटेड स्टेट्स ऑफ़िस ऑफ़ मैनेजमेंट एंड बजट (OMB) ने एक जारी किया ऐतिहासिक ज्ञापन अमेरिकी संघीय सरकार द्वारा स्वीकार्य स्तर तक आपकी सॉफ़्टवेयर आपूर्ति श्रृंखला को सुरक्षित करने के लिए आवश्यक कदमों के संबंध में। कोई भी कंपनी जो सरकार और सॉफ्टवेयर बनाने वाली किसी संघीय एजेंसी के साथ व्यापार करना चाहती है, उसे इसमें दी गई आवश्यकताओं और समय-सीमा का अनुपालन करना होगा। एम-22-18 मेमो.
एम-22-18 ने सॉफ्टवेयर आपूर्ति श्रृंखला की सुरक्षा और अखंडता की भूमिका पर विशेष ध्यान दिया एसओबीओएम. इसमें अनुपालन के लिए आवश्यक कदमों को लागू करने के लिए आवश्यकताओं की एक सूची और एक समयरेखा शामिल थी।
ज्ञापन में एनआईएसटी द्वारा निर्मित दो मुख्य दस्तावेज़ स्थापित किए गए: सिक्योर सॉफ्टवेयर डेवलपमेंट फ्रेमवर्क (एसएसडीएफ), एसपी 800-218, तथा सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा मार्गदर्शन सुरक्षित सॉफ्टवेयर विकास पर एनआईएसटी के मार्गदर्शन के रूप में। ज्ञापन में संघीय एजेंसियों को अपने उत्पादों का उपयोग करने के लिए स्वतंत्र होने से पहले एनआईएसटी के मार्गदर्शन के साथ अपने अनुपालन को स्वयं प्रमाणित करने की सॉफ्टवेयर उत्पादकों की जिम्मेदारी भी रेखांकित की गई है। यह स्व-सत्यापन एक हस्ताक्षरित स्व-सत्यापन "सामान्य प्रपत्र" का रूप लेना है। सॉफ़्टवेयर की तीन श्रेणियों के लिए इस स्व-सत्यापन फॉर्म की आवश्यकता होती है: नए सॉफ़्टवेयर की खरीदारी, प्रमुख संस्करण अपग्रेड, और सॉफ़्टवेयर नवीनीकरण।
एम-22-18 के लिए सीआईएसए को उस ज्ञापन की तारीख (120 सितंबर, 14) से 2022 दिनों के भीतर इस मानक स्व-सत्यापन "सामान्य फॉर्म" को स्थापित करने की आवश्यकता थी। जनवरी 120 में वे 2023 दिन बीत चुके हैं लेकिन फॉर्म अभी भी मौजूद है मसौदा प्रपत्र भले ही इसके लिए टिप्पणी की अवधि 26 जून, 2023 को बंद हो गई। यह लगभग तब है जब ओएमबी मेमो ने मूल रूप से एजेंसियों को महत्वपूर्ण सॉफ़्टवेयर के लिए सत्यापन एकत्र करना शुरू करने का निर्देश दिया था।
उस सामान्य सत्यापन फॉर्म के लिए प्राप्त कुछ टिप्पणियों के आधार पर, ओएमबी ने 22 जून, 18 को एम-9-2023 में एक संशोधन जारी करना उचित समझा। इस संशोधन का शीर्षक है एम 23-16. नया ज्ञापन एजेंसियों के लिए सॉफ्टवेयर उत्पादकों से सत्यापन एकत्र करने के लिए एम-22-18 पर प्रकाशित समयसीमा को बढ़ाता है। एजेंसियों को अब इसे एकत्र करना आवश्यक है स्व-सत्यापन "सामान्य प्रपत्र" "महत्वपूर्ण" सॉफ़्टवेयर के लिए सॉफ़्टवेयर उत्पादकों से CISA सामान्य स्व-सत्यापन फॉर्म OMB द्वारा अनुमोदित होने के तीन महीने के भीतर नहीं। अन्य सभी सॉफ्टवेयर उत्पादकों के पास स्व-सत्यापन फॉर्म ओएमबी द्वारा अनुमोदित होने के बाद छह महीने का समय होता है।
इसके बाद से ऐसा प्रतीत होता है कि मानक स्व-सत्यापन फॉर्म केंद्र स्तर पर है, आइए थोड़ा और विस्तार से देखें कि इसमें क्या शामिल है। हम यह भी देखेंगे कि वास्तव में इस पर हस्ताक्षर करने वाला कौन है और ऐसे हस्ताक्षर का क्या मतलब होगा।
सुरक्षित सॉफ़्टवेयर स्व-सत्यापन सामान्य प्रपत्र
ईओ 14028 से एनआईएसटी के मार्गदर्शन पत्रों से लेकर ओएमबी मेमो तक विनियमन की श्रृंखला के बाद, यह स्पष्ट है कि सरकार का लक्ष्य संघीय एजेंसियों और निजी क्षेत्र की कंपनियों दोनों को सभी की रक्षा करना है। सॉफ़्टवेयर आपूर्ति श्रृंखला की कमजोरियाँ और घुसपैठ. चूंकि निजी क्षेत्र ने इसके बारे में पर्याप्त काम नहीं किया है (सरकार के विचार में) सरकार ने नए नियम बनाने की योजना बनाई है जिसका पालन हर किसी को (जो संघीय सरकार को बेचता है) करना होगा।
निःसंदेह, भले ही आप संघीय सरकार को नहीं बेचते (अभी तक) इन नियमों का पालन करना और स्वयं प्रमाणित करना आपके हित में है कि आप 'सुरक्षित' हैं क्योंकि ऐसी कंपनियां अधिक आकर्षक व्यावसायिक भागीदार बनने जा रही हैं। कौन ऐसी कंपनी के साथ व्यापार करना चाहेगा जो पुष्टि नहीं कर सकती कि वे अपने उत्पाद और उपयोगकर्ताओं की सुरक्षा के लिए हर संभव प्रयास कर रही हैं?
चूंकि हमने पहले ही स्थापित कर दिया है कि एनआईएसटी मार्गदर्शन नए विनियमन और सर्वोत्तम प्रथाओं का आधार है, इसलिए इसमें कोई आश्चर्य की बात नहीं है कि वही सुझाव सामने आते हैं, उदाहरण के लिए, एसएसडीएफ स्व-सत्यापन प्रपत्र में भी प्रदर्शित करें।
यहां मसौदा दस्तावेज़ से एक संक्षिप्त उदाहरण दिया गया है:
हम बाईं ओर संबंधित ईओ अनुभाग और फिर एसएसडीएफ प्रथाओं और कार्यों के बाद आवश्यकता को देख सकते हैं। यह आवश्यकताओं की एक बहुत विस्तृत सूची है (डेढ़ पृष्ठ) जो जरूरी नहीं कि पूरी तरह से स्पष्ट हो यदि पाठक साइबर सुरक्षा और/या DevOps या DevSecOps के व्यवसाय में नहीं है।
दस्तावेज़ में कंपनी के हस्ताक्षरकर्ता को व्यक्तिगत रूप से प्रमाणित करने की आवश्यकता होती है कि फॉर्म में उल्लिखित सभी आवश्यकताओं को लगातार बनाए रखा जाता है और यदि सूची में कोई भी तत्व अब वैध नहीं है तो कंपनी प्रभावित एजेंसियों को सूचित करेगी।
दस्तावेज़ यह निर्दिष्ट नहीं करता है कि कंपनी में किसे दस्तावेज़ पर हस्ताक्षर करना चाहिए, लेकिन चूंकि कंपनी के लिए संघीय सरकार और उसकी एजेंसियों के साथ व्यापार करने के लिए यह फॉर्म आवश्यक है, तो इसका कारण यह है कि सीईओ वह व्यक्ति है जिसे ज़िम्मेदारी लेनी चाहिए यहाँ। सीईओ संभवतः इस पर आंख मूंदकर हस्ताक्षर नहीं करेंगे और अपने सीटीओ और सीआईएसओ को यह सत्यापित करने के लिए कहेंगे (संभवतः लिखित रूप में) कि कंपनी इन सभी दिशानिर्देशों और आवश्यकताओं का पालन करती है।
चूँकि इन सभी आवश्यकताओं को एकत्र करने और प्रमाणित करने के लिए कोई स्थापित उत्पाद या संचालन का तरीका नहीं है, एक अर्थ में हस्ताक्षर करने वाली प्रत्येक कंपनी को अपने लिए 'पहिया का फिर से आविष्कार' करने की आवश्यकता है और आशा है कि कुछ भी बुरा नहीं होगा।
यदि कुछ बुरा होता है तो संघीय सरकार यह दिखाने और साबित करने के लिए हस्ताक्षरकर्ता के पीछे जाएगी कि वे सभी प्रपत्रों की आवश्यकताओं का समर्थन कर सकते हैं।
यदि मैं हस्ताक्षर न करूँ तो क्या होगा?
सबसे पहले, यह संपूर्ण सत्यापन चीज़ वर्तमान में केवल तभी प्रासंगिक है यदि आपका सॉफ़्टवेयर किसी संघीय एजेंसी द्वारा उपयोग किया जा रहा है, यदि आप अपना सॉफ़्टवेयर संघीय सरकार को बेचने का इरादा रखते हैं, या, यदि आपका सॉफ़्टवेयर किसी विक्रेता द्वारा उपयोग किया जा रहा है जिसका सॉफ़्टवेयर या तो उपयोग में है या संघीय सरकार को बेचने का इरादा है।
ध्यान दें कि मैंने 'वर्तमान में' कहा था क्योंकि इस बात के हर संकेत हैं कि एसएसडीएफ अनुपालन, या तो स्व-सत्यापन के रूप में या किसी अन्य सत्यापन योग्य रूप में, सॉफ्टवेयर उत्पादन के क्षेत्र में एक नया 'सर्वोत्तम अभ्यास' बनने जा रहा है।
इसलिए, यह मानते हुए कि आपकी कंपनी ऊपर उल्लिखित समूह में आती है और आप स्पष्ट विवेक के साथ इस दस्तावेज़ पर हस्ताक्षर करने का रास्ता नहीं ढूंढ पा रहे हैं, अभी सब कुछ ख़त्म नहीं हुआ है। जब तक आप समझा सकें कि सत्यापन में कहां कमी है और संतोषजनक प्रस्ताव दें कार्य योजना और मील के पत्थर (POA&M) विचाराधीन संघीय एजेंसी अभी भी आपके उत्पाद को खरीद/उपयोग कर सकती है और ओएमबी से आपकी ओर से आपके सॉफ़्टवेयर के लिए एक्सटेंशन प्राप्त कर सकती है।
बुरी खबर यह है कि POA&M योजना के साथ या उसके बिना, आपको अंततः एक पूर्ण सत्यापन फॉर्म प्रदान करने की आवश्यकता होगी, जिसका अर्थ है कि आपको संघीय अदालत में यह सत्यापित करने में सक्षम होना होगा कि फॉर्म के लिए आवश्यक सभी चरणों का आपकी कंपनी द्वारा पालन किया गया था और आपका सॉफ़्टवेयर विकास प्रक्रिया कम से कम फ़ॉर्म की आवश्यकताओं जितनी सुरक्षित है।
एकमात्र सॉफ़्टवेयर जो वर्तमान में सत्यापन के इस रूप से मुक्त है, वह संघीय-एजेंसी-विकसित सॉफ़्टवेयर और स्वतंत्र रूप से उपलब्ध सॉफ़्टवेयर, AKA ओपन-सोर्स सॉफ़्टवेयर है। निःसंदेह, अधिकांश सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा आपके कोड में कुछ ओपन-सोर्स पैकेज में छेद का किसी तरह से पता लगाया जा सकता है, लेकिन ओपन-सोर्स डेवलपर्स और अनुरक्षकों, जो मुफ्त में काम करते हैं, को अपने सॉफ़्टवेयर के लिए कानूनी रूप से बाध्यकारी गारंटी प्रदान करने के लिए मजबूर करने की कोशिश करना एक वास्तविक मुद्दा है। ओपन-सोर्स सॉफ़्टवेयर का उपयोग करने वाले किसी भी व्यक्ति को इसकी सुरक्षा को सामान्य रूप से सत्यापित करना चाहिए और जब उस सॉफ़्टवेयर की बात आती है जिसमें यह विशेष रूप से एम्बेडेड होता है।
इससे भी बदतर मामला परिदृश्य
यह संपूर्ण सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा कर्तव्यनिष्ठा प्रसिद्ध के बाद शुरू हुई ओरियन हैक. बहुत अधिक विवरण में जाए बिना, हैक के समय, 18,000 संघीय एजेंसियों सहित कंपनी के 9 से अधिक ग्राहक प्रभावित हुए थे।
अब, वर्षों बाद, हम इस घटना के कुछ कानूनी परिणाम देखना शुरू कर रहे हैं। सेकंड, अमेरिकी प्रतिभूति और विनिमय आयोग, कंपनी के पीछे जा रहा है समग्र रूप से और साथ ही कई सी-स्तर के अधिकारियों के बाद भी. इसे सरकार के इरादों के एक उदाहरण के रूप में देखा जा सकता है, अगर ऐसी कोई घटना या इसी तरह की घटना किसी सॉफ्टवेयर निर्माता के साथ घटी हो, जिसने अपनी सुरक्षित विकास प्रथाओं को प्रमाणित किया हो और फिर भी हैक का शिकार हो गया हो।
सोलरविंड्स के मामले में, कंपनी ऐसी कानूनी कार्रवाई के निशाने पर आने वाले किसी भी कर्मचारी का पूरी तरह से समर्थन कर रही है। अमेरिकी कानूनी प्रणाली को जानने के बाद, ऐसे मामलों में वर्षों लगने और बहुत सारा पैसा खर्च होने की संभावना है। जुर्माने का सवाल ही नहीं उठता और अनुमान के आधार पर यह रकम लाखों तक पहुंच सकती है नुकसान उठाना पड़ा.
आप कल्पना कर सकते हैं कि सभी कंपनियाँ, विशेष रूप से छोटी और मध्यम कंपनियाँ, अपने कर्मचारियों की उतनी सुरक्षा नहीं करतीं जितनी कि सोलरविंड्स करती हैं। समस्या यह है कि यदि आरोपी पक्ष कंपनी का सीईओ है तो इस बात की वास्तविक संभावना है कि कंपनी और उसके उत्पाद पर बाजार का भरोसा गंभीर रूप से प्रभावित होगा। मोटी जेब वाली एक बड़ी कंपनी के समर्थन के बिना एसईसी का सामना करना एक संदिग्ध सीईओ के साथ-साथ उनकी कंपनी को भी बर्बाद कर सकता है। बेशक, इरादा यह है कि लोग विकास को सुरक्षित करने की अपनी ज़िम्मेदारी को गंभीरता से लें, लेकिन डर के कारण लोग आत्म-संरक्षण के पक्ष में गलती कर सकते हैं। इसका मतलब यह है कि लोग साइबर सुरक्षा घटनाओं को छिपाना पसंद करेंगे यदि उन्हें लगता है कि वे संभावित एसईसी मामले को नहीं जीत सकते हैं या उन्हें चिंता है कि ऐसे मामले की लागत और खराब प्रचार इतना गंभीर होगा कि अदालती मामले के नतीजे की परवाह किए बिना उन्हें छिपाना बेहतर होगा।
मैं कैसे हस्ताक्षर कर सकता हूँ?
एनआईएसटी एसएसडीएफ मार्गदर्शन सुझावों और सर्वोत्तम प्रथाओं से भरा है लेकिन व्यावहारिकताओं पर प्रकाश डालता है। चूँकि प्रत्येक कंपनी अद्वितीय है, इसलिए ऐसा उत्पाद या प्रणाली लाना काफी कठिन है जो सभी के लिए काम करे। इस मामले में, निजी क्षेत्र रिक्तता को भरने के लिए कदम बढ़ा रहा है, और आवश्यकताओं का पालन करने में आपकी सहायता के लिए एक पारिस्थितिकी तंत्र बना रहा है।
उदाहरण के लिए, मुंशी ने एक मंच बनाया सत्यापन बनाने, उन पर हस्ताक्षर करने और उन्हें सत्यापित करने की क्षमता प्रदान करने की अवधारणा पर आधारित है। हम जल्द ही इसके अनुरूप एक दस्तावेज़ जारी करेंगे सीआईएसए स्व-सत्यापन फॉर्म, यह दर्शाता है कि स्क्राइब समाधान आवश्यकताओं के प्रत्येक अनुभाग में आपकी कैसे मदद कर सकता है। बने रहें।
कठिन परीक्षा लेना स्क्राइब का मंच निःशुल्क है। मैं आपको इसे आज़माने और यह देखने के लिए प्रोत्साहित करता हूं कि आप इस प्लेटफ़ॉर्म को अपनी आवश्यकताओं के अनुसार कैसे फिट कर सकते हैं और साथ ही स्पष्ट विवेक के साथ सीआईएसए के स्व-सत्यापन फॉर्म पर हस्ताक्षर करें।
यह सामग्री आपके लिए स्क्राइब सिक्योरिटी द्वारा लाई गई है, जो एक अग्रणी एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा समाधान प्रदाता है - जो संपूर्ण सॉफ्टवेयर आपूर्ति श्रृंखलाओं में कोड कलाकृतियों और कोड विकास और वितरण प्रक्रियाओं के लिए अत्याधुनिक सुरक्षा प्रदान करता है। और अधिक जानें.