DevSecOps के लिए उपयुक्त साइबर रणनीति बनाना

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

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

याद रखने योग्य बात यह है कि न केवल DevOps डिलीवरी बल्कि भौतिक डेटा स्टोर भी सुरक्षित होना चाहिए ताकि पर्यावरण रैंसमवेयर हमलों, बड़े पैमाने पर कोड लीक, या इससे भी बदतर, ग्राहक डेटा लीक का लक्ष्य न बने। .

DevSecOps सुरक्षा अक्सर डेवलपर्स के हाथों में आती है। किसी ऐसी चीज़ के लिए बिक्री बोली में स्वीकृत आवश्यकता जो शायद अतीत में नहीं की गई हो, किसी निर्दोष डेवलपर के डेस्क पर आ जाती है। सभी विकास टीमों में एक समान भावना थी, “यह हमारा काम नहीं है।” अब तक, ऐसा इसलिए नहीं था क्योंकि कोड काम करने के लिए बनाया गया था, बल्कि इसलिए कि यह सुरक्षित था।

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

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

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

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

सफलता की कुंजी यह सुनिश्चित करना है कि डिलीवरी पाइपलाइन में हर कोई सुरक्षा जवाबदेही साझा करता है और यह कि सब कुछ जवाबदेह स्टॉप गेट्स के साथ जितना संभव हो उतना स्वचालित है।

DevSecOps रणनीति का केंद्र सुरक्षा आधारभूत सामान्य भेद्यताएँ और जोखिम हैं (सीवीईसुरक्षा विचलन अनुरोधों और सुरक्षा समस्या प्रबंधन के लिए जोखिम/लाभ विश्लेषण के साथ संयुक्त जोखिम सहिष्णुता की ट्रैकिंग और परिभाषा। CVE DevSecOps की रीढ़ हो सकती है। आपके ऐप में निश्चित रूप से निर्भरताएं हैं। यह जावा, अपाचे, या यहां तक ​​कि Log4J जैसा कुछ भी हो सकता है, ये सभी आपके ऐप की सुरक्षा से गंभीर रूप से समझौता कर सकते हैं।

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

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

सीवीई को ट्रैक करना बेहद मुश्किल है, और कुछ अनुप्रयोगों में दशकों से डेवलपर्स काम कर रहे हैं।हो सकता है ऐप्स में छिपी 10 साल पुरानी निर्भरता, आधुनिक देव इसके बारे में कुछ नहीं सोचते हैं, लेकिन “यह एक कारण के लिए होना चाहिए”, है ना? मेरे पास है। उस विक्रेता से सुरक्षा नोटिस की तलाश कौन कर रहा है?शायद नहीं। इसके लिए स्वचालन महत्वपूर्ण है। इन चेकों को स्वायत्त रूप से चलाने के लिए पाइपलाइन में CVE चेकर्स को घोंसला बनाना आवश्यक है।

DevSecOps टूल को कई कारकों की पहचान करनी चाहिए और उन्हें सहसंबंधित करना चाहिए और आईटी सेवा प्रबंधन टूल के साथ एकीकृत करना चाहिए ताकि सुरक्षा और गैर-सुरक्षा कर्मियों को सूचित निर्णय लेने में मदद मिल सके। लेकिन प्रभावी DevSecOps को नए टूल से अधिक की आवश्यकता होती है। जल्दी या बाद में सुरक्षा टीमों के काम को एकजुट करने के लिए एक सांस्कृतिक बदलाव की आवश्यकता है।

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

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