अमेरिकी सरकार को सॉफ्टवेयर बेच रहे हैं? पहले सुरक्षा सत्यापन जानें

अमेरिकी सरकार को सॉफ्टवेयर बेच रहे हैं? पहले सुरक्षा सत्यापन जानें

अमेरिकी सरकार को सॉफ्टवेयर बेच रहे हैं? सुरक्षा सत्यापन को पहले जानें प्लेटोब्लॉकचेन डेटा इंटेलिजेंस। लंबवत खोज. ऐ.

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

नई सॉफ़्टवेयर सुरक्षा आवश्यकताएँ: क्या बदल गया है?

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

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

समझने वाली सबसे महत्वपूर्ण चीजों में से एक यह है कि संगठनों को केवल यह प्रमाणित नहीं करना चाहिए कि वे अपने द्वारा लिखे गए सॉफ़्टवेयर कोड के लिए स्वयं इन प्रथाओं का पालन करते हैं, बल्कि यह भी कि वे अपने अनुप्रयोगों में जो ओपन सोर्स घटक खींचते हैं वे भी इन प्रथाओं का पालन करते हैं।

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

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

एम-23-16 के अनुसार, गैर-अनुपालन के लिए जुर्माना गंभीर है:

“[संघीय] एजेंसी को अवश्य करना चाहिए सॉफ़्टवेयर का उपयोग बंद करें यदि एजेंसी सॉफ़्टवेयर निर्माता के दस्तावेज़ीकरण को असंतोषजनक पाती है या यदि एजेंसी यह पुष्टि करने में असमर्थ है कि निर्माता ने उन प्रथाओं की पहचान की है जिन्हें वह प्रमाणित नहीं कर सकता है…”

ओपन सोर्स का विशेष रूप से चुनौतीपूर्ण मामला

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

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

आपका संगठन अपनी स्वयं की सुरक्षा प्रथाओं को प्रमाणित कर सकता है, लेकिन आप अपने अनुप्रयोगों में उपयोग किए जाने वाले ओपन सोर्स कोड को लिखने और बनाए रखने वाले ओपन सोर्स अनुरक्षकों द्वारा अपनाई जाने वाली सुरक्षा प्रथाओं को वास्तव में कैसे प्रमाणित कर सकते हैं?

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

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

इस समस्या को हल करने का एक बेहतर तरीका यह सुनिश्चित करना है कि जिन पैकेजों पर आप भरोसा करते हैं उनके रखरखाव करने वालों को इस महत्वपूर्ण सुरक्षा कार्य को करने के लिए भुगतान किया जा रहा है।

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

एक चुनौतीपूर्ण लेकिन आवश्यक कदम

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

समय टिकट:

से अधिक डार्क रीडिंग