क्या ऑटोटेस्ट कमजोरियों की तलाश में एक व्यक्ति को बदल सकता है: एलेक्जेंड्रा स्वेटिकोवा के साथ साक्षात्कार

एलेक्जेंड्रा स्वेटिकोवा ओडनोक्लासनिक में एक सूचना सुरक्षा विशेषज्ञ के रूप में काम करता है। 8 साल पहले, उसने जावा में विकसित होने से अनुप्रयोग सुरक्षा का परीक्षण किया।

हमने उसका साक्षात्कार किया जहां हमने चर्चा की:

• क्या डेवलपर के लिए एप्लिकेशन एनालिटिक्स पर स्विच करना मुश्किल है?
• पेंटर, रिसचर और विश्लेषक के प्रदर्शन में अंतर;
• सुरक्षा विकास जीवनचक्र या एसडीएलसी;
• कमजोरियों की तलाश में आदमी की भूमिका;
• कैसे अन्य कंपनियों में सुरक्षा विश्लेषिकी के साथ चीजें हैं।

इस लेख में कोई कट्टर नहीं होगा - आप उसे हेइसेनबग 2019 मास्को में पालन ​​कर सकते हैं, जहां एलेक्जेंड्रा स्थैतिक सुरक्षा परीक्षण के बारे में बात करेगी। हम पोस्ट के अंत में उसकी रिपोर्ट पर जाएंगे, लेकिन अभी के लिए, बिल्ली में आपका स्वागत है।

अनुप्रयोग सुरक्षा में प्रवेश करना उतना मुश्किल नहीं है जितना लगता है

"आपने किसके लिए अध्ययन किया?" आप आवेदन सुरक्षा में शामिल क्यों हो गए?

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

- आपको क्या लगता है, क्या आप इस क्षेत्र में लंबे समय तक रहेंगे, या कुछ और इस चरण का पालन करेंगे?

- मुझे लगता है कि मैं हमेशा के लिए रहूंगा, क्योंकि मैं 2011 से एक एप्लीकेशन सिक्योरिटी एनालिस्ट रहा हूं। मेरे पास पहले से ही कम विकास का अनुभव है, यह पता चला है। प्रोग्रामर को नियमित कार्यों से डरना नहीं चाहिए, बग को ठीक करना चाहिए, लेकिन सुरक्षा विशेषज्ञ की एक अलग विशिष्टता है, यह मुझे अधिक आकर्षित करता है।

- पारंपरिक विकास की तुलना में आपको किन अतिरिक्त क्षेत्रों में महारत हासिल करनी है?

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

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

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

- और कुछ इंजीनियरिंग, उदाहरण के लिए, नेटवर्क स्टैक, आपको खरोंच से सीखना था? उदाहरण के लिए, जेएस, फ्रंट, बैकिंग कैसे काम करता है?

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

- यह आपको कितना वास्तविक लगता है कि अमूर्त पूर्ण-स्टैक डेवलपर या एक पूर्ण-स्टैक टेस्टर, जो प्रोग्रामिंग, स्वचालन और परीक्षण में लगा हुआ है, अनुप्रयोगों के विश्लेषण पर जाएगा, यानी आप क्या कर रहे हैं?

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

डेवलपर्स प्रक्रिया में उनकी भागीदारी को थोड़ा अलग तरीके से देखते हैं। इसलिए, डेवलपर के लिए यह एक क्रांति है, पेशे पर एक अलग नज़र है। डेवलपर के लिए यह महत्वपूर्ण है कि कुछ काम करता है, लेकिन उसके लिए इसे तोड़ना मुश्किल होगा।

Pentester, rescher और अनुप्रयोग सुरक्षा विश्लेषक: क्या अंतर है

- जैसा कि मैं इसे समझता हूं, आपकी विशेषज्ञता पेंटेस्टर्स से संबंधित है। पेन्टेस्टर्स और शून्य-दिन भेद्यता शोधकर्ताओं की तुलना कैसे करते हैं, या क्या यह सब एक बोतल में मिलाया जाता है और क्या वास्तव में यह पता लगाना मुश्किल है कि कौन है?

- पदों में कोई स्पष्ट विभाजन नहीं है। लेकिन मैं आपको बताता हूं कि पार्टी किन शब्दों का उपयोग करती है।

एक दिलचस्प समस्या खोजने के प्रयास में एक उत्पाद, प्रौद्योगिकी, प्रोटोकॉल, सर्वर पर शोध करने वाले स्काउट्स हैं। दिलचस्प एक समस्या को संदर्भित करता है जो पहले नहीं पाया गया था, या एक अप्रत्याशित जगह में पहचाना गया था, या यह पहले से ज्ञात समस्याओं का एक जटिल संयोजन है। मैं कह सकता हूं कि एक नियम के रूप में, स्काउट्स द्वारा सभी प्रकार की 0day कमजोरियां पाई जाती हैं।

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

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

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

- फिर आवेदन सुरक्षा विश्लेषक इस प्रक्रिया में, दिन-प्रतिदिन करता है?

- हाँ, और एक ही समय में, गतिविधि दो दिशाओं में निर्देशित होती है। एक तरफ, आपको मौजूदा कमजोरियों की तलाश करने और उनका मुकाबला करने की आवश्यकता है। दूसरी ओर, सिस्टम को सुरक्षित बनाने के लिए एक कार्य है।

इसके लिए अलग-अलग तरीकों से संपर्क किया जा सकता है। उदाहरण के लिए, विकास प्रक्रिया का निर्माण करें ताकि कम त्रुटियां हों या उनका शीघ्र पता लगाया जा सके। या तंत्र को लागू करें जो जोखिम को कम कर देगा कि भेद्यता उत्पादन में गिर जाएगी। सिस्टम सुरक्षा सुनिश्चित करने के कई तरीके हैं।

- तो, ​​एप्लीकेशन सिक्योरिटी एनालिटिक्स का काम टीमों के साथ घनिष्ठ रूप से जुड़ा हुआ है और विकास प्रक्रिया बिल्कुल अंदर?

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

कमजोरियों को खोजने में मानव मन अभी भी अपरिहार्य है

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

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

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

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

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

यदि आवेदन को खरोंच से लिखा गया है, तो आप कोड में संदिग्ध निर्देशों से बचने के लिए एक स्थिर विश्लेषक का उपयोग करने की पेशकश कर सकते हैं। और अगर आपने 10 साल पहले कोड लिखा था, और आप पागल पैसे के लिए अपने टूल के साथ वहां आए, तो, निश्चित रूप से, आप थोड़ा पाएंगे।

सभी स्वचालित टूल में यह समस्या है कि उन्हें सिस्टम के काम करने के तरीके के बारे में जानकारी नहीं है। यदि सिस्टम के एक व्यक्तिगत घटक को अलग किया जा सकता है, तो इसे तैयार उपकरणों के साथ परीक्षण किया जा सकता है। लेकिन कई निर्भरता वाली प्रणाली में, स्वचालित स्कैनर बहुमूल्य जानकारी खो सकते हैं।

अन्य कंपनियों में सुरक्षा विश्लेषण

- कौन सी कंपनी या कौन सी व्यक्तिगत परियोजना, आपकी राय में, कंपनी के भाषणों और सम्मेलन प्रस्तुतियों के आधार पर एप्लीकेशन सिक्योरिटी एनालिटिक्स में प्रमुख है?

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

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

यदि हम रूसी कंपनियों को लेते हैं, तो Sberbank ने दिलचस्प बात की कि उन्होंने कैसे SDLC को औपचारिक रूप दिया, प्रक्रिया का दस्तावेजीकरण किया। हालाँकि उनकी एप्लिकेशन सुरक्षा टीम बड़ी है, लेकिन यह कई डेवलपर्स के लिए पर्याप्त नहीं है। इसलिए, वे टीमों में सुरक्षा चैंपियन को शिक्षित करते हैं, सुरक्षा के बारे में कुछ ज्ञान अपने सिर में डालते हैं, और जिस स्थिति में चैंपियन लाल झंडा उठा सकते हैं।

Yandex सम्मेलनों में "एक ब्राउज़र को हैक करने के तरीके" के बारे में बात करता है।

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

- आप 10 हज़ार डॉलर (हंसते हुए) के लिए एक स्कैनर नहीं खरीद सकते। अगर हम कमजोरियों की खोज के बारे में बात करते हैं, तो यह विशिष्ट परिदृश्यों के परीक्षण के लिए नीचे आता है। परिदृश्य सामान्य ज्ञान के संग्रह से लिए गए हैं।

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

मानक और धोखा पत्रक मैनुअल परीक्षण चलाने के लिए पर्याप्त हैं। यह कहता है कि किस प्रकार की कमजोरियां मौजूद हैं और उन्हें कैसे देखना है। कुछ परीक्षण मानक स्कैनरों द्वारा परिभाषा के अनुसार नहीं किए जा सकते हैं: उदाहरण के लिए, व्यापार तर्क की जाँच से संबंधित।

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

लेकिन जब आप स्कैनर शुरू करते हैं, तो तीन परिदृश्य हो सकते हैं:

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

इसलिए, मुझे लगता है कि यह समझना महत्वपूर्ण है कि स्कैनर "हुड के नीचे" है, ताकि हल किए जा रहे कार्य के अनुरूप टूल का चयन किया जा सके और परिणाम का पर्याप्त मूल्यांकन किया जा सके।

अलेक्जेंडर हाइजेनबग पर अपनी रिपोर्ट में उपकरणों की सही पसंद और ट्यूनिंग के विषय को विकसित करेगा। वहाँ वह अपने प्रोजेक्ट में कमज़ोरियों को खोजने के लिए SAST-समाधान सोनारक्यूब और फाइंड सिक्योरिटी बग्स के अनुप्रयोग और अनुकूलन के बारे में बात करेगी। ये उपकरण "बॉक्स से बाहर" क्या सुविधाएँ प्रदान करते हैं? और उनकी कार्यक्षमता को अपने दम पर कैसे बढ़ाया जाए? एक उदाहरण के रूप में, स्पीकर XSS और IDOR की कमजोरियों पर विचार करेगा।

सम्मेलन मास्को में 5-6 दिसंबर को आयोजित किया जाएगा ।