100 में 1: सिक्योरिटी गैप को पाटने के लिए टीम कैसे डिज़ाइन करें

100 में 1

यहां तक ​​कि अगर आप एक बड़े संगठन के लिए काम करते हैं, तो संभावना है कि आप आईटी में काम करने वाले सभी सुरक्षा लोगों के नाम याद कर सकते हैं। क्योंकि हालिया सर्वेक्षण के अनुसार, डेवलपर्स के सुरक्षा का अनुपात 100: 1 है, (वही अध्ययन ऑप्स के देवों के 10: 1 अनुपात को इंगित करता है)। पिछले अध्ययनों ने 100: 3 से 100: 6 तक अनुपातों की रिपोर्ट की है, इसलिए कुछ प्रगति हुई है लेकिन पर्याप्त तेजी से नहीं।

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

हम अभी भी एक दुष्चक्र के अंदर हैं जहां सुरक्षा विशेषज्ञता पर्याप्त आकर्षक नहीं है क्योंकि, ऐतिहासिक रूप से, कंपनियों ने सुरक्षा को पर्याप्त प्राथमिकता नहीं दी है। उन्हीं कंपनियों को अब अपने सुरक्षा खेल को बढ़ाने की जरूरत है, लेकिन उनके पास लोगों की कमी है।

तो इस सुरक्षा अंतर को पाटने के लिए हमारे पास क्या विकल्प हैं?

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

तो अंतर कहां है? यह "हैकर मानसिकता" में है, हमारे अनुप्रयोगों ("अज्ञात अज्ञात") में नए संभावित हमलावर वैक्टर के लिए एक निरंतर खोज। और यह सार्थक जोखिम विश्लेषण और धमकी मॉडलिंग और कार्यों और प्राथमिकताओं में अनुवाद के कठिन कार्य में भी है। इसके लिए गहरी सुरक्षा सोच और पृष्ठभूमि की आवश्यकता होती है, यह नहीं है कि कुछ उत्पाद विकास टीमों को उनकी मौजूदा जिम्मेदारियों के ऊपर जोड़े गए संज्ञानात्मक भार के रूप में लेने के लिए कहा जा सकता है।

मैथ्यू स्केल्टन और मैंने जो काम किया है, उसे अलग-अलग DevOps टोपोलॉजी कैसे विकसित और सूचीबद्ध करती है, यह समझाने और DevOps को अपनाने या अवरुद्ध करने में महत्वपूर्ण भूमिका निभा सकता है।

दो अलग (और संभवतः पूरक) टीम टोपोलॉजी का ख्याल आता है:

ए) पूरी तरह से साझा सुरक्षा जिम्मेदारियां

बी) एक सक्षम टीम के रूप में सुरक्षा

प्रत्येक दृष्टिकोण के अंतर, पेशेवरों और विपक्ष क्या हैं?

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

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

लक्ष्य सुरक्षा व्यक्ति को सभी सुरक्षा कार्यों को आवंटित करने के लिए नहीं है, अन्यथा हम केवल एक मैक्रो स्तर (अलग सुरक्षा टीम) पर एक माइक्रो-स्तर (पृथक टीम सदस्य) के लिए एक साइलो को स्थानांतरित कर रहे हैं।
प्रत्येक उत्पाद टीम - 7 से 9 टीम के सदस्यों के साथ एक पीले वृत्त के रूप में चित्रित किया गया है, जहां कम से कम एक टी-आकार का सुरक्षा व्यक्ति है - जिसे हरे रंग के सर्कल के अंदर दर्शाया गया है - लेकिन अन्य लोग भी सुरक्षा कार्य में भाग लेते हैं

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

पेशेवरों

  • टीम सुरक्षा स्वामित्व बढ़ेगा, जिससे तेज (गैर-तुच्छ) सुरक्षा घटना समाधान हो सकता है और शायद इससे भी महत्वपूर्ण, भविष्य में दर्द को दोहराने से बचने के लिए उनसे सीखना।
  • चूंकि टीमों के पास एक प्राकृतिक आकार सीमा (8–9 लोग) हैं, इसलिए आईटी टीम के कर्मचारियों का अनुपात सुरक्षा (टी-आकार) के कर्मचारियों के अनुपात में इस टीम टोपोलॉजी के साथ समय के साथ 10: 1 के करीब हो जाना चाहिए। अकेले तकनीकी पृष्ठभूमि में विविधता समस्याओं और प्राथमिकताओं के दृष्टिकोण के संदर्भ में लाभ लाएगी।
  • इस टोपोलॉजी के लिए कदम संगठन में हर किसी के लिए एक निर्विवाद संकेत भेजेगा कि सुरक्षा अब हमारे उत्पादों में एक प्रथम श्रेणी का नागरिक है।

विपक्ष

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

heuristics

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

यदि उपरोक्त प्रश्नों में से एक और का उत्तर सकारात्मक है, तो यह टोपोलॉजी सुरक्षा अंतर को दूर करने के लिए उपयुक्त साबित हो सकती है।

सक्षम टीम के रूप में सुरक्षा का मतलब है कि समर्पित विकास टीम उत्पाद विकास टीमों को समर्थन और मार्गदर्शन (उदाहरण के लिए, सुरक्षित विकास दिशानिर्देशों का निर्माण) प्रदान करती है।

महत्वपूर्ण रूप से, केंद्रीकृत सुरक्षा टीम वास्तविक सुरक्षा विश्लेषण और कार्यान्वयन कार्य नहीं करती है, इसके बजाय यह आवश्यक होने पर प्रचार और मार्गदर्शन करती है।

यह समान रूप से महत्वपूर्ण है कि यह टीम परियोजना के शुरू से ही शामिल है या जीवनचक्र के प्रत्येक चरण में उत्पाद टीम को सुरक्षा निहितार्थ, दृष्टिकोण और प्रथाओं पर विचार करने में मदद करने के लिए जारी करती है।

एक ट्रांसवर्सल सुरक्षा दल - जो ग्रे में लंबवत दर्शाया गया है - तीन उत्पाद टीमों का समर्थन करता है - नारंगी में क्षैतिज रूप से चित्रित - जिसके परिणामस्वरूप सुरक्षा के लिए साझा जिम्मेदारी है - एक हल्के हरे रंग के सर्कल के रूप में चित्रित किया गया है

कई संगठनों ने इसे अपनाया है, जिसमें Spotify और Sportradar शामिल हैं। हमें पारंपरिक "सुरक्षा टीम साइलो" से बहुत कम संरचनात्मक परिवर्तन की आवश्यकता है, क्योंकि हम अनिवार्य रूप से इस टीम की जिम्मेदारियों (कार्यान्वयन के बजाय मार्गदर्शन और समर्थन) को स्थानांतरित कर रहे हैं। लेकिन इससे बाकी संगठन को पूरी तरह से एहसास हो सकता है कि उत्पाद टीमों को अपने सिस्टम की सुरक्षा का अधिक स्वामित्व लेने की उम्मीद है।

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

उत्पाद सुरक्षा कार्य करने के बजाय मार्गदर्शन प्रदान करने वाली एक केंद्रीकृत सुरक्षा टीम की भूमिका (क्रेडिट: पाब्लो जेन्सेन, स्पोर्टरार में सीटीओ - उसकी क्यूसन लंदन 2018 प्रस्तुति से स्लाइड)

पेशेवरों

  • छोटे समय सीमा सुरक्षा काम के थोक कर रही एक पारंपरिक पृथक सुरक्षा टीम से एक सक्षम मॉडल में स्थानांतरित करने के लिए।
  • बड़ी संख्या में नए किराए की आवश्यकता नहीं होगी, इस प्रकार सभी संबद्ध प्रयासों और संभावित टीम व्यवधान से बचना होगा। यहां ध्यान केंद्रित करना चाहिए ताकि यह सुनिश्चित हो सके कि सक्षम टीम के पास तकनीकी कौशल के शीर्ष पर आवश्यक सभी नरम कौशल हैं।

विपक्ष

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

heuristics

  • क्या उत्पाद विकास टीमों की थोड़ी संख्या है (सुरक्षा टीम के साथ निकट सहयोग की अनुमति)?
  • क्या उत्पाद टीम के सदस्य सीखने के लिए सुरक्षा विषयों और भूख में रुचि प्रदर्शित करते हैं (उदाहरण के लिए तकनीकी सम्मेलनों या मीटअप में भाग लेना)?
  • क्या उत्पादन में सुरक्षा संबंधी घटनाओं के समाधान में स्वाभाविक रूप से सुरक्षा और विकास दोनों लोगों को शामिल किया जाता है (जैसा कि दोष के खेल के विपरीत है, जहां प्रत्येक पक्ष जिम्मेदारी से दूर हो जाता है)?

यदि उपरोक्त प्रश्नों में से एक और का उत्तर सकारात्मक है, तो यह टोपोलॉजी सुरक्षा अंतर को दूर करने के लिए उपयुक्त साबित हो सकती है।

निष्कर्ष

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

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

आपने अपने संगठनों या ग्राहकों में कौन सी अन्य टीम टोपोलॉजी और सुरक्षा रणनीति देखी है? कृपया नीचे टिप्पणी करें या मुझे ईमेल करें:

मुझे मैनुअल डॉट नेट पर