स्टीव विल्सन के साथ सुरक्षा में सुधार पर

स्टीव विल्सन कंट्रास्ट सिक्योरिटी में मुख्य उत्पाद अधिकारी हैं, जिनके पास साइट्रिक्स, ओरेकल और सन माइक्रोसिस्टम्स जैसी बहु-अरब डॉलर की प्रौद्योगिकी कंपनियों में उत्पादों के विकास और विपणन का 25 वर्षों का अनुभव है। इस एएमए में, स्टीव हमें सर्वर रहित सुरक्षा, जावा पारिस्थितिकी तंत्र में एप्लिकेशन सुरक्षा, SBOMs और सर्वोत्तम प्रथाओं के बारे में बताता है। मोनिका फ्रीटास, स्टीव विल्सन, ज़ैच टेलर, विक्टर डी एविला, जैक बोरहम और सारा पिंटो का यह स्लोगिंग थ्रेड स्लोगिंग के आधिकारिक #amas चैनल में हुआ, और इसे पठनीयता के लिए संपादित किया गया है। अरे @चैनल, कृपया हमारे अगले एएमए अतिथि स्टीव विल्सन का स्वागत करने में मेरे साथ शामिल हों। स्टीव वर्तमान में कंट्रास्ट सिक्योरिटी में मुख्य उत्पाद अधिकारी हैं। आज उनकी टीम सभी उत्पादों के लिए इंजीनियरिंग, उत्पाद प्रबंधन और उत्पाद डिजाइन के लिए जिम्मेदार है। स्टीव के पास साइट्रिक्स, ओरेकल और सन माइक्रोसिस्टम्स जैसी बहु-अरब डॉलर की प्रौद्योगिकी कंपनियों में उत्पादों के विकास और विपणन का 25 से अधिक वर्षों का अनुभव है। कंट्रास्ट से पहले, स्टीव Citrix Cloud के उत्पाद प्रबंधन के उपाध्यक्ष थे, जहां उन्होंने Citrix उत्पादों को पारंपरिक ऑन-प्रिमाइसेस से SaaS में बदलने का नेतृत्व किया।

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

कृपया बेझिझक स्टीव से इस बारे में कुछ भी पूछें:

हाय स्टीव विल्सन! आपका हमारे साथ होना बहुत अच्छा है! क्या आप हमें अपनी पृष्ठभूमि के बारे में और कंट्रास्ट सुरक्षा के साथ काम करने के तरीके के बारे में बताकर शुरुआत कर सकते हैं?

हाय मोनिका फ्रीटास! यहां आकर बहुत अच्छा लग रहा है। मैं सबसे पहले हैकरनून को उनके एएमए में शामिल होने के लिए धन्यवाद देते हुए शुरू करना चाहता हूं और मैं आपके सवालों के जवाब देने के लिए उत्सुक हूं।

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

मेरे बारे में 2 मजेदार तथ्य:
- मेरे पास ताइक्वांडो में सेकेंड-डिग्री ब्लैकबेल्ट है।
- मुझे गिटार पर क्लासिक रॉक ट्यून्स बजाने में मजा आता है।

बेझिझक मुझे पर फॉलो करें धन्यवाद, मोनिका फ्रीटास, इस बारे में बात करके खुशी हुई कि मैं कंट्रास्ट में कैसे आया! मैं लगभग 18 महीने पहले Citrix, Oracle और Sun Microsystems जैसी बड़ी कंपनियों में काम करने के बाद शामिल हुआ था। मैंने इंजीनियरिंग और उत्पाद प्रबंधन दोनों में व्यक्तिगत योगदानकर्ता और प्रबंधन भूमिकाओं में काम किया है, 90 के दशक के उत्तरार्ध में जावा टीम के शुरुआती सदस्य के रूप में अपने दिनों में वापस जाना। यदि लोग रुचि रखते हैं तो प्रारंभिक जावा/सन ट्रिविया के बारे में प्रश्नों का उत्तर देने में प्रसन्नता हो रही है। मैं त्वरित कहानी हालांकि मैं कंट्रास्ट में कैसे आया। अपनी पिछली भूमिका में, मैं ऐसी स्थिति में आ गया था, जहां खराब "कोड स्कैनिंग" उत्पाद चलाने वाली सुरक्षा टीम द्वारा सैकड़ों इंजीनियरों की एक टीम पूरी तरह से पटरी से उतर गई थी। इसने हमारे लिए भारी मात्रा में तकनीकी ऋण उत्पन्न किया (जिसे हमें संबोधित करने की आवश्यकता थी), लेकिन हमारी सुरक्षा मुद्रा में लगभग कोई सुधार नहीं हुआ। इसने शेड्यूल को खिसका दिया और भारी निराशा पैदा की। कंट्रास्ट में शामिल होने से, मुझे एहसास हुआ कि ऐसा करने का एक बेहतर तरीका था! हाय स्टीव! क्या आप बता सकते हैं कि सर्वर रहित क्या है? धन्यवाद, जैच टेलर! सर्वर रहित उन शब्दों में से एक है जिसका अर्थ बहुत सारे लोगों के लिए बहुत कुछ है, तो चलिए इसे तोड़ते हैं। संक्षेप में, यह तकनीकों का एक सेट है जिसे सर्वर-साइड कंप्यूटिंग को अधिक कुशल और सरल बनाने के लिए डिज़ाइन किया गया है। शब्द का एक उपयोग "वर्चुअल मशीन" (एला वीएमवेयर) की भारी-वजन अवधारणा को दूर करने के विचार के बारे में है और हल्के वजन का उपयोग करने के बजाय, डॉकर कंटेनर और कुबेरनेट्स जैसे स्केलेबल निर्माण। हालांकि, मुझे लगता है कि सर्वर रहित के अंदर एक और अधिक दिलचस्प आंदोलन चल रहा है ... एप्लिकेशन आर्किटेक्चर के लिए 20 वर्षों में सबसे बड़ी क्रांति एक सेवा के रूप में कार्य है। इसका सबसे लोकप्रिय उदाहरण अमेज़ॅन वेब सर्विसेज (एडब्ल्यूएस) लैम्ब्डा है - हालांकि माइक्रोसॉफ्ट और गूगल जैसे अन्य बादलों ने समान निर्माण जोड़े हैं। जिस तरह जावा सर्वलेट्स वेब आर्किटेक्चर बनाम "सीजीआई" में बड़े पैमाने पर सुधार थे, उसी तरह सर्वरलेस फ़ंक्शन पारंपरिक आर्किटेक्चर की तुलना में 100x तेज और सस्ता हो सकता है। ये फ़ंक्शन हर समय मज़ेदार नहीं होते हैं, वे अधिक "घटना-आधारित" होते हैं और केवल आवश्यकता होने पर ही चलते हैं। आप देखते हैं कि इनका उपयोग उन जगहों पर किया जा रहा है जहाँ बड़े पैमाने पर मापनीयता और कम लागत महत्वपूर्ण है। इंटरनेट ऑफ थिंग्स (IoT) एप्लिकेशन जहां आप हजारों या लाखों उपकरणों से डेटा वापस डेटा-संग्रह सेवा में भेज सकते हैं। यह वाकई रोमांचक चीज है।

यह डेवलपर्स के लिए बहुत रोमांचक है! और जब आप IoT का उल्लेख करते हैं, तो ऐसा लगता है कि यह कई अलग-अलग उपयोग के मामलों के द्वार खोलता है।

सर्वर रहित सुरक्षा, पारंपरिक अनुप्रयोग सुरक्षा से किस प्रकार भिन्न है?

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

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

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

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

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

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

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

लेकिन, विस्तार से बताने के लिए, मैं Oracle में तब शामिल हुआ जब उन्होंने Sun Microsystems का अधिग्रहण किया। मैं वास्तव में 90 के दशक के मध्य में जावा डेवलपर किट पर काम करने वाले एक कोडर के रूप में सन में शामिल हुआ, जहां मुझे जेम्स गोस्लिंग (और कई अन्य जो प्रसिद्ध प्रोग्रामर बन गए हैं और भयानक चीजें बनाई हैं) जैसे सभी प्रकार के स्मार्ट लोगों के साथ काम करने को मिला। मैंने जावा जीयूआई टूलकिट पर काम करना शुरू किया और फिर जावा के लिए पहला पूर्णकालिक प्रदर्शन इंजीनियर बन गया। दरअसल, मैंने इसके बारे में एक लिखी थी। मैं केवल मनोरंजन के लिए एक लिंक प्रदान करूंगा, लेकिन यह बहुत पुराना है और मैं किसी को भी इसे अभी पढ़ने का सुझाव नहीं दूंगा! मैं मैं प्रबंधन में चला गया और नेटबीन्स आईडीई टीम (मेरी पसंदीदा नौकरी, बीटीडब्लू) और फिर सन की वर्चुअलाइजेशन और सिस्टम प्रबंधन टीमों का नेतृत्व किया। मुझे बताएं कि क्या आप इसके किसी भी हिस्से के बारे में अधिक प्रश्न पूछना चाहते हैं। Sun/Oracle के बारे में बहुत सारी मज़ेदार कहानियाँ।

स्टीव विल्सन यह एक शानदार यात्रा है!
कंट्रास्ट में अपनी भूमिका में आपको किन चुनौतियों का सामना करना पड़ा? और स्वयं-सेवा सुरक्षा समाधान से आपका क्या तात्पर्य है? क्या आपके पास सुरक्षा समाधानों का एक स्थापित सेट है और कोई भी कंपनी केवल वही चुन सकती है जो उनकी आवश्यकता के अनुरूप हो? क्या व्यवसायों के लिए अनुरूप समाधान के लिए कंट्रास्ट से पूछना संभव है?

मोनिका फ्रीटास, कंट्रास्ट के बारे में पूछने के लिए धन्यवाद! कंट्रास्ट एक ऐसी कंपनी है जो डेवलपर्स को सुरक्षित एप्लिकेशन बनाने में मदद करने के लिए टूल में माहिर है। जब वे सुरक्षा (और यह महत्वपूर्ण है) पर विचार करते हैं, तो बहुत से लोग नेटवर्क, पहचान या समापन बिंदु सुरक्षा उपकरण जैसी चीजों के बारे में सोचते हैं, लेकिन हम सभी हैकर्स से बचाने की क्या कोशिश कर रहे हैं? यह वास्तव में हमारे अनुप्रयोगों और डेटा के बारे में है जो वे हमारे लिए संग्रहीत कर रहे हैं। इसलिए एप्लिकेशन सुरक्षा इतनी महत्वपूर्ण है और वे उपकरण हैं जो कंट्रास्ट बनाता है। हमारे पास एक सुरक्षित कोड प्लेटफॉर्म है जिसे कहा जाता है। इसमें डेवलपर्स और सुरक्षा टीमों की मदद करने के लिए कई प्रौद्योगिकियां शामिल हैं। इसमें सोर्स कोड स्कैनिंग (एसएएसटी), इंस्ट्रूमेंटेशन शामिल है जो "इनसाइड आउट" से आपके ऐप का परीक्षण कर सकता है) आईएएसटी, रनटाइम प्रोटेक्शन (आरएएसपी) जो वास्तव में शून्य-दिन की कमजोरियों का फायदा उठाने की कोशिश कर रहे हमलावरों को बेअसर कर सकता है। हाल के उदाहरण Log4J और Spring4Shell जैसी चीजें हैं। और अंत में, हमने हाल ही में क्लाउड-नेटिव सर्वरलेस कोड के लिए दुनिया का पहला सुरक्षा टूल पेश किया है। हमें लोगों से DevSecOps प्रोग्राम बनाने के सर्वोत्तम विकल्पों के बारे में बात करने में खुशी होगी जो उन्हें अपने विकास वेग को बनाए रखने की अनुमति देगा, लेकिन यह भी सुनिश्चित करेगा कि उनका कोड सुरक्षित है। आप अधिक विवरण के लिए पहुंच सकते हैं। मोनिका फ़्रीटास, "स्वयं-सेवा" सुरक्षा के विषय पर... स्वयं-सेवा सुरक्षा समाधान डेवलपर्स के लिए कॉन्ट्रास्ट टूल का स्वयं लाभ उठाने की क्षमता को संदर्भित करता है और उनका उपयोग करता है कि वे सबसे अच्छी तरह से कैसे फिट होते हैं। इसका मतलब यह है कि डेवलपर्स और DevOps टीमों को केवल वे उपकरण मिल सकते हैं जिनकी उन्हें काम करने के लिए आवश्यकता होती है और न्यूनतम सुरक्षा प्रशिक्षण (या एक समर्पित सुरक्षा इंजीनियरिंग टीम से निरंतर निरीक्षण) के साथ कमजोरियों को ढूंढ और ठीक कर सकते हैं। कंट्रास्ट के अनुरूप समाधान के लिए पूछने के लिए, बिल्कुल। हमारी टीम टीमों का मार्गदर्शन करने में सक्षम है कि उनके उद्देश्यों के साथ-साथ दीर्घकालिक और अल्पकालिक जरूरतों के आधार पर सबसे अच्छा क्या काम करेगा। स्टीव विल्सन, आपने सबसे आम सुरक्षा मुद्दे क्या देखे हैं और कंपनियां उन्हें हल करने के लिए क्या कदम उठा सकती हैं? मोनिका फ्रीटास, सबसे आम सुरक्षा मुद्दों के बारे में प्रश्न के लिए धन्यवाद। मैं फ़िशिंग और खराब पासवर्ड जैसी चीज़ों से दूर रहने जा रहा हूँ (क्योंकि यह स्पष्ट और अच्छी तरह से ट्रोड ग्राउंड है)। इसके बजाय, मैं सुरक्षित एप्लिकेशन बनाने में आने वाली समस्याओं पर ध्यान दूंगा। दो मुख्य चीजें हैं जिन पर आपको ध्यान देने की आवश्यकता है: आपके द्वारा लिखे गए कोड को सुरक्षित करना और आपके द्वारा उपयोग किए जाने वाले कोड को सुरक्षित करना जो किसी और ने लिखा है (आमतौर पर ओपन-सोर्स)। आपके द्वारा लिखे गए कोड के साथ, बहुत बड़ी संख्या में भेद्यता प्रकार हैं जिन्हें वर्गीकृत किया गया है। सबसे आम (और सबसे गंभीर) में से एक को "इंजेक्शन" हमला कहा जाता है। इसका मतलब यह है कि एक बाहरी इकाई (एक हैकर!) आपके सिस्टम के कुछ हिस्से में डेटा को इस तरह से डालने में सक्षम है जिसका आपने अनुमान या इरादा नहीं किया था। ये "एसक्यूएल इंजेक्शन अटैक" जैसी चीजें हो सकती हैं जहां एक हैकर डेटाबेस क्वेरी भाषा का एक टुकड़ा आपके डेटाबेस में डाल सकता है और इसे दूरस्थ रूप से निष्पादित कर सकता है। यह वास्तव में आम है और 20 वर्षों से एक शीर्ष समस्या रही है। एक और जिसे अक्सर कम गंभीर माना जाता था वह है "लॉग फ़ाइल इंजेक्शन" जहां एक हैकर दागी डेटा को सीधे आपके ऐप की लॉग फ़ाइल में डालने में सक्षम होता है। ऐसा लगता है कि यह बहुत बुरा नहीं है, लेकिन यह हाल ही में Log4J सुरक्षा घटना के केंद्र में था जिसने दिसंबर/जनवरी में कई कंपनियों को प्रभावित किया था। ओपन-सोर्स कोड के लिए, हम जानते हैं कि आधुनिक व्यावसायिक ऐप्स में अधिकांश कोड कंपनी के डेवलपर्स द्वारा भी नहीं लिखे गए हैं। यह ओपन-सोर्स है। यह सभी प्रकार के हमलों के लिए खुला है और जबकि ओपन सोर्स कोड पर कई आंखें रखकर सुरक्षित कोड के लिए एक ठोस आधार प्रदान करता है, उनमें से कई आंखें अब हैकर्स (छात्रों से लेकर राष्ट्र-राज्य हैकर्स तक) हैं। इनमें से कुछ पुस्तकालय (जैसे स्ट्रट्स, लॉग4जे, स्प्रिंग) इतने लोकप्रिय हैं कि वे दुनिया भर के लाखों ऐप्स में एम्बेड किए गए हैं। कुछ साल पहले, इक्विफैक्स नामक क्रेडिट रेटिंग एजेंसी स्ट्रट्स के एक कमजोर संस्करण का उपयोग कर रही थी और लाखों अमेरिकियों के व्यक्तिगत वित्तीय डेटा को खो दिया था। परिणामस्वरूप उन पर $400,000,000 डॉलर से अधिक का जुर्माना लगाया गया। यह गंभीर है। इन दोनों समस्याओं से निपटने का सबसे अच्छा तरीका यह है कि आप अपने विकास के तरीकों को आधुनिक बनायें ताकि इस तरह की समस्याओं का पता लगाने और उन्हें दूर करने में आपकी मदद करने वाले स्वचालित उपकरण शामिल हों। कंट्रास्ट का सुरक्षित कोड प्लेटफ़ॉर्म जावा, जावास्क्रिप्ट .NET, गो, रूबी, पायथन, स्काला और कोटलिन के साथ काम करता है, इसलिए यदि आप इनमें से किसी भी लोकप्रिय तकनीक का उपयोग कर रहे हैं तो हमें आपके टूल को आधुनिक बनाने और सभी को स्वचालित करने के लिए एक प्रोग्राम बनाने में मदद करने में खुशी होगी। इस का। अरे स्टीव विल्सन! मैं उत्सुक हूँ, SBOMs क्या हैं? क्या वे सुरक्षा प्रणालियों को प्रभावित कर सकते हैं? सारा पिंटो, SBOM के बारे में पूछने के लिए धन्यवाद। अभी इतना दिलचस्प और सामयिक क्षेत्र! यह वास्तव में सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा नामक बड़े विषय का एक हिस्सा है। जैसा कि इस थ्रेड के कुछ अन्य प्रश्नों में उल्लेख किया गया है, आधुनिक ऐप्स में अधिकांश कोड कंपनी के अपने डेवलपर्स द्वारा नहीं लिखे गए हैं। यह किसी तृतीय-पक्ष (अक्सर ओपन-सोर्स) से होता है। कुछ समय पहले, सोलर विंड्स नामक एक सॉफ्टवेयर विक्रेता को हैक कर लिया गया था। यह सौर हवाओं के लिए बुरा था, लेकिन इससे भी बुरी बात यह थी कि सोलर विंड्स कोड बनाया गया था जो कई अन्य कंपनियों और यहां तक कि सरकारों के क्लाउड और डेटा सेंटर वातावरण में अंतर्निहित था। यह जानते हुए, सोलरविंड्स पर हमला करने वाले हैकर्स ने न केवल सोलरविंड्स से चोरी की, उन्होंने सोलरविंड के सॉफ्टवेयर में पिछले दरवाजे लगाने के अवसर का उपयोग किया, जिसे बाद में कई अन्य कंपनियों द्वारा एम्बेड किया जाएगा। अन्वेषण बड़े पैमाने पर था और इससे यह विचार आया कि आपको अपने कोड का ट्रैक रखना चाहिए, लेकिन वह कोड भी जो आप कहीं और से प्राप्त कर रहे हैं। पूरी प्रक्रिया अंत से अंत तक सुरक्षित होनी चाहिए और इसे सॉफ़्टवेयर आपूर्ति श्रृंखला सुरक्षा कहा जाता है। SBOM का मतलब सॉफ्टवेयर बिल ऑफ मैटेरियल है। एक SBOM एक कोडबेस में मौजूद सभी ओपन-सोर्स और तीसरे पक्ष के घटकों की एक सूची है, जो उन घटकों को नियंत्रित करने वाले सभी लाइसेंसों के अतिरिक्त है। इसे एक खाद्य बॉक्स के किनारे पर पोषण लेबल के रूप में सोचें। यह एक उपभोक्ता को यह जानने में मदद करता है कि भोजन में क्या है ताकि वे इसका उपयोग यह सुनिश्चित करने के लिए कर सकें कि भोजन उनके लिए सुरक्षित और स्वस्थ है। SBOMs सॉफ़्टवेयर बाज़ार में अधिक पारदर्शिता पैदा कर सकते हैं और यदि भेद्यता की पहचान की गई है तो डेवलपर्स को शीघ्रता से कार्य करने की अनुमति भी दे सकते हैं। हाल के में कहा गया है कि SBOM की आवश्यकता होनी चाहिए और NTIA ने " जारी किया, और इनमें से कई बिंदुओं पर केवल और साथ में पर बिडेन के हालिया वक्तव्य में जोर दिया गया था। . इसके अलावा, गार्टनर ने भविष्यवाणी की है कि 2025 तक, महत्वपूर्ण बुनियादी ढांचे के सॉफ्टवेयर का निर्माण या खरीद करने वाले 60% संगठन SBOM को अपने सॉफ्टवेयर इंजीनियरिंग अभ्यास में अनिवार्य और मानकीकृत करेंगे। हालांकि ये आधुनिक अनुप्रयोगों को हासिल करने के लिए बेहतरीन पहला कदम हैं-जिसमें सर्वर रहित-डेवलपर्स और सुरक्षा दल अभी भी अपने अनुप्रयोगों को सुरक्षित रखने के लिए हुक पर हैं, और यह जिम्मेदारी DevSecOps टीमों पर आती है। स्टीव विल्सन, जैसा कि Web3 विकसित होता है, क्या आप web3 के लिए सुरक्षा विकल्प बनाने की संभावना पर विचार करते हैं? मोनिका फ्रीटास, इस प्रश्न के लिए धन्यवाद वेब3 सुरक्षा बहुत अधिक है। यह एक आकर्षक और काफी व्यापक विषय है। मैं अपना दृष्टिकोण जोड़ने की कोशिश करूंगा। सबसे पहले, हमें Web3 को परिभाषित करना होगा। लोकप्रिय संस्कृति में, डिजिटल कला के अजीब टुकड़ों के व्यापार में वेब 3 का विचार हावी है। पोंजी योजनाओं और धोखाधड़ी पर लगातार चर्चा हो रही है। लेकिन मुझे लगता है कि Web3 की अवधारणाएं आकर्षक हैं। जब आप इसे पूरी तरह से हटा देते हैं, तो वेब3 बहुत सारे इंटरनेट को खरोंच से पुनर्निर्माण करने के प्रयासों का एक साहसिक सेट है (और मुझे यकीन है कि कई असफल होंगे)। हमें ऐसा करने की आवश्यकता क्यों है? खैर, यह वास्तव में सुरक्षा और विश्वास के बारे में है! इंटरनेट और इसके ऊपर बैठे विश्व-व्यापी वेब को शिक्षाविदों द्वारा शिक्षाविदों के लिए बनाया गया था। वे सूचना खोलने, विज्ञान और प्रौद्योगिकी को आगे बढ़ाने और विचारों के आदान-प्रदान को बढ़ावा देने के लिए थे। इस अर्थ में, इंटरनेट/वेब मानव इतिहास का सबसे सफल प्रयास है।

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

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

इसने मुझे व्यक्तिगत रूप से वास्तव में गोता लगाने के लिए प्रेरित किया कि ब्लॉकचेन कैसे काम करता है। कुछ मायनों में, यह एक कंप्यूटर विज्ञान चमत्कार है, और कुछ मायनों में, यह एक इंजीनियरिंग दुःस्वप्न है, लेकिन इसने अवधारणाओं के एक नए सेट का बीड़ा उठाया है कि आप केंद्रीय प्राधिकरण के बिना विश्वास कैसे वितरित करते हैं। यह web3 का मूल है! मुझे कैसे पता चलेगा कि आप कौन हैं और आप क्या हैं (एक निश्चित संदर्भ में) बीच में किसी तीसरे पक्ष के संस्थान के बिना मुझे बताए? यदि आप ब्लॉकचेन के अच्छे और बुरे पर मेरे विचारों को पढ़ने में रुचि रखते हैं तो आप इस को देख सकते हैं। यह कुछ साल पुराना है, लेकिन यहां मूल अवधारणाएं इतनी धीमी गति से आगे बढ़ रही हैं कि यह चर्चा के लिए काफी हद तक प्रासंगिक है। तो, अब चलो पीतल के टैक के लिए नीचे उतरें! वेब3 सुरक्षा में गोता लगाने के इच्छुक किसी व्यक्ति को मैं क्या बताऊंगा? सबसे पहले, छोटे ब्लॉकचेन में सुरक्षा विफलताओं के हाई-प्रोफाइल उदाहरण हैं। ब्लॉकचैन ट्रस्ट आम तौर पर आम सहमति मतदान पर आधारित होता है और यदि आपके पास महत्वपूर्ण द्रव्यमान नहीं है, तो किसी के पास 50% से अधिक वोट हो सकते हैं और आप मुश्किल में हैं। हालांकि, मुझे नहीं लगता कि आज वेब3 को देखने वाले डेवलपर्स के लिए यह सबसे महत्वपूर्ण विषय है। जब मैं हाल के वर्षों में Web3/NFT/Crypto के आसपास की बड़ी सुरक्षा घटनाओं को देखता हूं, तो वे कोर ब्लॉकचेन से संबंधित नहीं हैं। वे एक कंपनी के कोड/बुनियादी ढांचे के Web2 भागों के आसपास हैं जो अभी भी दुनिया को एक साथ जोड़ते हैं। Web3 प्ले, बहुत लंबी अवधि में (दशकों के संदर्भ में सोचें) खेल, इंटरनेट के आधार को उन चीजों से बदलना है जिसमें एक मुख्य घटक के रूप में विश्वास शामिल है। ऐसा हो सकता है, और यह प्रशंसनीय है, लेकिन यह बहुत दूर है। आज, हमारे पास IPv4/6, SSL, HTML, JavaScript, REST, AppServers, ओपन-सोर्स लाइब्रेरी और SQL डेटाबेस जैसी चीज़ें हैं जो दुनिया को एक साथ रखती हैं (ब्लॉकचेन/वेब3 प्रौद्योगिकियों के द्वीपों के साथ)। यदि आप एक एनएफटी एक्सचेंज (या कुछ इसी तरह) चला रहे हैं तो मैं अपने समय का उतना ही (या अधिक) खर्च करूंगा जो मेरी दुनिया के वेब 2 हिस्से के बारे में चिंतित है जो मेरे और मेरे ग्राहकों/भागीदारों के बीच गोंद है। यह सभी समान एप्लिकेशन सुरक्षा अवधारणाओं के लिए अतिसंवेदनशील है जिनके बारे में हमने यहां पहले बात की है। आपको एक महान DevSecOps कार्यक्रम और मंच की आवश्यकता है। और इसमें से अधिकांश क्रेडिट कार्ड प्रोसेसर या एक प्रमुख बैंक के समान दिखना चाहिए। कंट्रास्ट यहां मदद कर सकता है। यदि आप अपने Web2 "गोंद" को एक प्रमुख बैंक के समान स्तर तक सख्त कर सकते हैं, तो आप अपना समय इस चिंता में बिता सकते हैं कि Web3 की दुनिया में कैसे अंतर किया जाए। यह रोमांचक समय है। मैं यह देखने के लिए इंतजार नहीं कर सकता कि यह कैसे विकसित होता है। अगर आप इस विषय पर और बात करना चाहते हैं तो मुझे बताएं। मुझे चैट करना अच्छा लगेगा! स्टीव विल्सन, मैं इन सभी सॉफ़्टवेयर सुरक्षा मानकों के लिए नया हूँ। क्या आप उनके बारे में विस्तार से बता सकते हैं? मुझे इसके बारे में क्या पता होना चाहिए? सारा पिंटो, सॉफ़्टवेयर सुरक्षा मानकों पर प्रश्न के लिए धन्यवाद। बहुत खूब! आपने अभी बहुत बड़े और महत्वपूर्ण विषय पर प्रहार किया है। मोटे तौर पर दो प्रकार के मानक हैं: संविदात्मक/वाणिज्यिक और वैधानिक। वाणिज्यिक मानक ऐसी चीजें हैं जो आपको व्यवसाय करने में मदद करेंगी। इन मानकों में से किसी एक का पालन करना एक अनुबंध में लिखा जा सकता है। उदाहरण के लिए, आपके ग्राहक की आवश्यकता हो सकती है कि आप SOC2 नामक मानक का पालन करें और इसे प्रदर्शित करने के लिए नियमित रूप से ऑडिट किया जाए। दूसरी ओर, क्लाउड कंप्यूटिंग सेवाओं को अमेरिकी सरकार को बेचने के लिए, आपको FedRAMP नामक मानकों के एक सेट का पालन करना होगा (जो कि "कानून द्वारा" है इसलिए इसे एक वैधानिक आवश्यकता माना जाता है)। यदि आप एक सॉफ्टवेयर/सास कंपनी चला रहे हैं तो ये दोनों उदाहरण दिलचस्प और महत्वपूर्ण हैं। हालांकि, व्यक्तिगत डेवलपर्स के लिए, वे वास्तव में सार हैं। उदाहरण के लिए, इन मानकों में केवल "सॉफ़्टवेयर" से परे बहुत सारी चीज़ें शामिल हैं। एक अच्छा उदाहरण होगा, क्या आपके पास अपने सभी कर्मचारियों के लिए पर्याप्त पृष्ठभूमि की जाँच और बुनियादी सुरक्षा प्रशिक्षण है?

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

साइबर सुरक्षा कार्यकारी आदेश 14028

पीसीआई एसएसएफ (प्रतिस्थापित पीए-डीएसएस)

ओडब्ल्यूएएसपी

निस्तो

सीआईएसए

ओएमबी

गोपनीयता (गोपनीयता के लिए सुरक्षा एक पूर्व शर्त है

अन्य

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