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

वादा-आधारित से साक्ष्य-आधारित सुरक्षा और आईटी के विकास की ओर बढ़ें

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

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

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

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

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

हम सुरक्षा कैसे करते हैं, इसमें बदलाव को गति देने वाले अन्य कारकों में शामिल हैं:

- परिणाम और सुरक्षा खर्च के बीच कमजोर संबंध,

- मापने योग्य परिणामों की मांग करने वाला व्यवसाय,

- सुरक्षा और ग्राहक परिवेश की बढ़ती जटिलता,

- सुरक्षा उपकरण प्रसार,

- सुरक्षा पेशेवरों की बढ़ती परिपक्वता,

- बढ़ती बीमा प्रीमियम,

- सेवा प्रदाताओं की नई पीढ़ी का उदय,

- सहायक विक्रेता पारिस्थितिकी तंत्र का उदय,

- सुरक्षा ढांचे की स्थापना, और

- साक्ष्य-आधारित सुरक्षा का निवेशक समर्थन।

भविष्य की साइबर सुरक्षा काफी हद तक सॉफ्टवेयर इंजीनियरिंग जैसी दिखने वाली है

सॉफ्टवेयर इंजीनियरिंग को साइबर सुरक्षा के लिए एक मॉडल के रूप में देखना

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

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

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

साइबर सुरक्षा के लिए सॉफ्टवेयर इंजीनियरिंग सिद्धांत

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

सबसे पहले, कल की सुरक्षा कोड के रूप में सुरक्षा होगी।

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

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

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

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

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

उत्पाद जीवन चक्र में सुरक्षा का स्थान

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

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

एजाइल को अपनाने से पहले जिसने क्रॉस-फंक्शनल टीमों के विचार को स्थापित किया, सॉफ्टवेयर विकास मोटे तौर पर इस प्रकार दिखता था:

1. एक उत्पाद प्रबंधक आवश्यकताओं को लिखता है और उन्हें डिजाइनरों को भेजता है
2. डिजाइनर मॉकअप का निर्माण करेंगे और उन्हें विकास दल को भेजेंगे
3. बैक-एंड इंजीनियर अपने हिस्से का काम पूरा करेंगे और बाकी हिस्सा फ्रंट-एंड टीम को भेजेंगे
4. फिर तैयार उत्पाद को समीक्षा के लिए क्यूए के पास भेजा गया

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

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

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

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

सुरक्षा बुनियादी ढांचे और संचालन के लिए इंजीनियरिंग मानसिकता

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

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

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

सुरक्षा के लिए एक इंजीनियरिंग मानसिकता को गले लगाने का मतलब कई चीजें हैं, जिनमें निम्न शामिल हैं:

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

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

सुरक्षा इंजीनियरिंग का उदय और यह कल की साइबर सुरक्षा को कैसे बदल रहा है

डिटेक्शन इंजीनियरिंग का विकास और एक सेवा के रूप में डिटेक्शन इंजीनियरिंग का उदय

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

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

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

सुरक्षा विक्रेता जो किसी के लिए कंबल कवरेज का वादा करते हैं और सभी एक महान बुनियादी परत हैं (एंटीवायरस के रूप में), लेकिन वे उन कंपनियों के लिए पर्याप्त नहीं हैं जिनके पास खोने के लिए बहुत कुछ है।

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

डिटेक्शन इंजीनियरिंग के बारे में बात करते हुए, जैक ने निष्कर्ष निकाला:

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

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

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

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

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

सुरक्षा इंजीनियरिंग का बढ़ता महत्व

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

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

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

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

एपडोम के टॉम टोवर ने अपने हालिया पॉडकास्ट में सुझाव दिया कि हम सुरक्षा संगठनों को तीन श्रेणियों में रख सकते हैं:

1. पारंपरिक सुरक्षा दल, सुरक्षा और अनुपालन के गहरे ज्ञान के साथ तकनीकी रूप से मजबूत सुरक्षा पेशेवरों से बना है, और दोनों के लिए सर्वोत्तम अभ्यास हैं।
2. उन्नत सुरक्षा दल जिनमें अक्सर सुरक्षा शोधकर्ता और सुरक्षा आर्किटेक्ट होते हैं जिन्हें डिजाइनिंग सिस्टम, उत्पाद मूल्यांकन, पैठ परीक्षण आदि का काम सौंपा जाता है।
3. साइबर सुरक्षा और इंजीनियरिंग संगठन जिनके पास "कट्टर" इंजीनियरिंग प्रतिभा है जो आधुनिक संगठनों के लिए सुरक्षा समाधान बनाने और वितरित करने में सक्षम हैं

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

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

सुरक्षा विश्लेषक भूमिका की बदलती प्रकृति

जैसे-जैसे साइबर सुरक्षा कोड बन जाती है, यह उन लोगों के लिए कठिन और कठिन होता जाएगा जो कोड नहीं करते हैं। मैं सुरक्षा विश्लेषकों की बदलती भूमिका के बारे में बात कर रहा हूं।

सुरक्षा विश्लेषक, पारंपरिक रूप से टियर 1 (ट्रिएज विशेषज्ञ), टियर 2 (घटना उत्तरदाता), और टियर 3 (विशेषज्ञ विश्लेषक) में वर्गीकृत, एक सुरक्षा संचालन केंद्र (SOC) टीम में महत्वपूर्ण भूमिका निभाते हैं। ऑटोमेशन में हालिया प्रगति के साथ, इस भूमिका का आकार बदलना शुरू हो गया है।

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

ऊपर वर्णित दो कारकों के कारण, SOC विश्लेषकों (विशेष रूप से जिन्हें पारंपरिक रूप से "टियर 1" के रूप में जाना जाता है) को नए कौशल सीखना शुरू करना होगा। सबसे जरूरी तकनीकी कौशल कोडिंग है, और विश्लेषक इसे समझते हैं जैसा कि 2022 में टाइन्स द्वारा कमीशन किए गए वॉयस ऑफ द एसओसी एनालिस्ट सर्वे द्वारा दिखाया गया है।

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

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

भविष्य का सुरक्षा ढेर

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

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

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

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

टैलेंट गैप को बंद करना

महान प्रतिभाओं को काम पर रखने के लिए, व्यवसाय को अपने काम करने के तरीके को बदलने की जरूरत है

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

यह पोस्टिंग इस तथ्य से जुड़ी है कि बहुत से बेहतरीन सुरक्षा पेशेवर बड़े निगमों के लिए काम करने की नौकरशाही से निपटने के लिए प्रेरित महसूस नहीं करते हैं, जो वर्तमान नौकरी बाजार की एक धूमिल तस्वीर पेश करता है।

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

सुरक्षा करने के लिए सॉफ्टवेयर इंजीनियर प्राप्त करना

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

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

सुरक्षा इंजीनियरों की नई पीढ़ी को शिक्षित करना

साइबर सुरक्षा में प्रतिभा की कमी के बारे में बहुत सारी बातें की जा रही हैं, और इस समस्या को हल करने का वादा करने वाले नए प्रवेशकों के समुद्र को नोटिस करना आसान है। 6-सप्ताह के साइबर सुरक्षा बूटकैंप से लेकर ऑनलाइन पाठ्यक्रम, साथ ही नए कॉलेज और विश्वविद्यालय की डिग्री - हर कोई "सुरक्षा के भविष्य को शिक्षित करने" में पाई का एक टुकड़ा चाहता है। यह सोचने के लिए ललचाता है कि हमें हाई स्कूल के छात्रों और वयस्कों को सुरक्षा के बारे में उत्साहित करियर बदलने और इन कार्यक्रमों में दाखिला लेने के लिए तैयार होने की जरूरत है, और 3-5 साल बाद हम पूरी तरह से तैयार हैं, मुझे लगता है कि समस्या बहुत गहरी हो रही है।

यदि आप शैक्षिक कार्यक्रमों के विशाल बहुमत को देखते हैं, तो आप ध्यान देते हैं कि उनके पाठ्यक्रम में इंजीनियरिंग घटक को छोड़ने की प्रवृत्ति होती है। मैंने डेटा को संकलित करने में पर्याप्त समय नहीं लगाया है, इसलिए इस विषय पर मेरी टिप्पणियां बल्कि उपाख्यानात्मक हैं, लेकिन यहां मैं देख रहा हूं:

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

यह सब कहने का एक लंबा तरीका है कि आज के सर्वश्रेष्ठ सुरक्षा पेशेवर विश्वविद्यालयों से नहीं आते हैं, और न ही जो ऐसा प्रतीत होता है वह कल से आएगा। जो लोग सुरक्षा इंजीनियरिंग में अग्रणी पेशेवर बनते हैं, वे पैठ परीक्षण, सैन्य, एनएसए, और मजबूत आक्रामक घटकों वाले अन्य सरकारी संस्थानों में व्यावहारिक नौकरियों से आते हैं। वे क्लाउड-नेटिव उद्यमों में परिपक्व सुरक्षा टीमों से आते हैं जो सुरक्षा को गंभीरता से लेते हैं। CTF (ध्वज को पकड़ना) प्रतियोगिताओं में, और Open SOC, Black Hat, DefCon, और इसी तरह की घटनाओं में उन्हें अपने कंप्यूटर के सामने स्व-सिखाया जाता है।

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

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

समापन विचार

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

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

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

इस लेख की मुख्य छवि हैकरनून केएआई इमेज जेनरेटर द्वारा प्रांप्ट "साइबर सुरक्षा" के माध्यम से तैयार की गई थी।