जोखिम स्क्यानिङ र सुरक्षित विकास। भाग 1

तिनीहरूको व्यावसायिक गतिविधिहरूको एक भागको रूपमा, विकासकर्ताहरू, पेन्टेस्टरहरू, र सुरक्षा पेशेवरहरूले जोखिम व्यवस्थापन (VM), (Secure) SDLC जस्ता प्रक्रियाहरूसँग व्यवहार गर्नुपर्छ।
यी वाक्यांशहरू तल प्रयोग गरिएका अभ्यासहरू र उपकरणहरूको विभिन्न सेटहरू छन् जुन एक अर्कामा जोडिएका छन्, यद्यपि तिनीहरूका प्रयोगकर्ताहरू फरक छन्।

पूर्वाधार र सफ्टवेयरको सुरक्षाको विश्लेषणका लागि एउटा उपकरणले व्यक्तिलाई प्रतिस्थापन गर्न सक्ने प्राविधिक प्रगति अहिलेसम्म पुगेको छैन।
यो किन यस्तो हुन्छ, र कुन समस्याहरूको सामना गर्नुपर्‍यो भनेर बुझ्न रोचक छ।

प्रक्रियाहरू

जोखिम व्यवस्थापन प्रक्रियालाई पूर्वाधार सुरक्षा र प्याच व्यवस्थापनको निरन्तर निगरानी गर्न डिजाइन गरिएको हो।
सुरक्षित SDLC प्रक्रिया ("सुरक्षित विकास चक्र") विकास र सञ्चालनको समयमा अनुप्रयोग सुरक्षा कायम गर्न डिजाइन गरिएको हो।

यी प्रक्रियाहरूको एक समान भाग हो जोखिम मूल्याङ्कन प्रक्रिया - जोखिम मूल्याङ्कन, जोखिम स्क्यानिङ।
VM र SDLC भित्र स्क्यानिङ बीचको मुख्य भिन्नता यो हो कि पहिलो अवस्थामा, लक्ष्य तेस्रो-पक्ष सफ्टवेयर वा कन्फिगरेसनमा ज्ञात कमजोरीहरू फेला पार्नु हो। उदाहरणका लागि, Windows को पुरानो संस्करण वा SNMP को लागि पूर्वनिर्धारित समुदाय स्ट्रिङ।
दोस्रो अवस्थामा, लक्ष्य भनेको तेस्रो-पक्ष कम्पोनेन्टहरू (निर्भरताहरू) मा मात्र होइन तर मुख्य रूपमा नयाँ उत्पादनको कोडमा कमजोरीहरू पत्ता लगाउनु हो।

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

पूर्वाधार स्क्यानर प्रायः टाइमरको साथ प्रतिस्थापन गर्न सकिन्छ, जस्तै avleonov। बिन्दु यो हो कि विशुद्ध रूपमा सांख्यिकीय रूपमा, तपाईंले आफ्नो पूर्वाधारलाई कमजोर मान्न सक्नुहुन्छ यदि तपाईंले यसलाई एक महिनासम्म अद्यावधिक गर्नुभएको छैन भने।

उपकरणहरू

स्क्यानिङ, साथै सुरक्षा विश्लेषण, कालो बक्स वा सेतो बक्सको रूपमा प्रदर्शन गर्न सकिन्छ।

कालो बक्स

ब्ल्याकबक्स स्क्यानिङको साथ, उपकरणले समान इन्टरफेसहरू मार्फत सेवासँग काम गर्न सक्षम हुनुपर्दछ जुन प्रयोगकर्ताहरूले यससँग काम गर्छन्।

पूर्वाधार स्क्यानरहरू (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, आदि) खुला नेटवर्क पोर्टहरू खोज्छन्, "ब्यानरहरू" सङ्कलन गर्छन्, स्थापित सफ्टवेयर संस्करणहरू पहिचान गर्छन्, र यी संस्करणहरूमा कमजोरीहरूको बारेमा जानकारीको लागि तिनीहरूको ज्ञानको आधार खोज्छन्। तिनीहरूले पूर्वनिर्धारित पासवर्डहरू वा डाटामा सार्वजनिक पहुँच, कमजोर SSL साइफरहरू, आदि जस्ता कन्फिगरेसन त्रुटिहरू पत्ता लगाउने प्रयास गर्छन्।

वेब अनुप्रयोग स्क्यानरहरू (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, आदि) ले ज्ञात कम्पोनेन्टहरू र तिनीहरूका संस्करणहरू (जस्तै CMS, फ्रेमवर्क, JS पुस्तकालयहरू) पनि पत्ता लगाउन सक्छन्। मुख्य क्रल चरणहरू क्रलिङ र फजिङ हुन्।
क्रलिङको समयमा, क्रलरले अवस्थित अनुप्रयोग इन्टरफेसहरू र HTTP प्यारामिटरहरूको बारेमा जानकारी सङ्कलन गर्दछ। फजिङको समयमा, सबै पत्ता लगाइएका प्यारामिटरहरू उत्परिवर्तित वा उत्पन्न डाटाको साथ प्रतिस्थापित हुन्छन् त्रुटिलाई उत्प्रेरित गर्न र कमजोरी पत्ता लगाउन।

त्यस्ता एप्लिकेसन स्क्यानरहरू DAST र IAST कक्षाहरूसँग सम्बन्धित छन् - क्रमशः गतिशील र अन्तरक्रियात्मक अनुप्रयोग सुरक्षा परीक्षण।

सेतो बाकस

व्हाइटबक्स स्क्यानिङको साथ, त्यहाँ धेरै भिन्नताहरू छन्।
VM प्रक्रियाको एक भागको रूपमा, स्क्यानरहरू (Vulners, Insecurity Couch, Vuls, Tenable Nessus, आदि) लाई प्राय: प्रमाणीकृत स्क्यान गरेर प्रणालीहरूमा पहुँच दिइन्छ। यसरी, स्क्यानरले नेटवर्क सेवा ब्यानरहरूबाट अनुमान नगरीकन प्रणालीबाट स्थापित प्याकेज संस्करणहरू र कन्फिगरेसन प्यारामिटरहरू डाउनलोड गर्न सक्छ।
स्क्यान अधिक सटीक र पूर्ण छ।

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

समस्याहरू

स्क्यानिङमा धेरै समस्याहरू छन्! मैले स्क्यानिङ र सुरक्षित विकास प्रक्रियाहरू निर्माण गर्नका लागि सेवाको प्रावधानको रूपमा, साथै सुरक्षा विश्लेषण कार्य सञ्चालन गर्दा व्यक्तिगत रूपमा तिनीहरूमध्ये धेरैसँग व्यवहार गर्नुपर्छ।

म समस्याहरूको 3 मुख्य समूहहरू एकल गर्नेछु, जुन विभिन्न कम्पनीहरूमा इन्जिनियरहरू र सूचना सुरक्षा सेवाहरूका प्रमुखहरूसँगको कुराकानीबाट पनि पुष्टि हुन्छ।

वेब अनुप्रयोग स्क्यानिङ मुद्दाहरू

1. कार्यान्वयनमा कठिनाई । प्रभावकारी हुनको लागि स्क्यानरहरू तैनाथ, कन्फिगर, प्रत्येक अनुप्रयोगको लागि अनुकूलित, स्क्यानहरूको लागि परीक्षण वातावरण आवंटित र CI / CD प्रक्रियामा लागू गर्न आवश्यक छ। अन्यथा, यो एक बेकार औपचारिक प्रक्रिया हुनेछ, केवल गलत सकारात्मक जारी
2. स्क्यान अवधि। 2019 मा पनि, स्क्यानरहरूले इन्टरफेसहरू घटाउनको लागि खराब काम गर्छन् र तिनीहरूका लागि एउटै कोड जिम्मेवार भए तापनि तिनीहरूलाई फरक विचार गर्दै, प्रत्येक दिन 10 प्यारामिटरहरू सहित हजार पृष्ठहरू स्क्यान गर्न सक्छन्। एकै समयमा, विकास चक्र भित्र उत्पादनमा खटाउने निर्णय छिटो हुनुपर्छ।
3. खराब सिफारिसहरू। स्क्यानरहरूले सामान्य सिफारिसहरू दिन्छन्, र विकासकर्ताको लागि तिनीहरूबाट जोखिमको स्तर कसरी कम गर्ने भनेर चाँडै बुझ्न सम्भव हुँदैन, र सबैभन्दा महत्त्वपूर्ण कुरा, यो अहिले नै गर्नु आवश्यक छ, वा यो अझै डरलाग्दो छैन।
4. आवेदन मा विनाशकारी प्रभाव। स्क्यानरहरूले सजिलैसँग एप्लिकेसनमा DoS आक्रमण गर्न सक्छन्, र तिनीहरूले ठूलो संख्यामा संस्थाहरू सिर्जना गर्न सक्छन् वा अवस्थितहरूलाई परिवर्तन गर्न सक्छन् (उदाहरणका लागि, ब्लगमा हजारौं टिप्पणीहरू सिर्जना गर्नुहोस्), त्यसैले तपाईंले सोचविचार नगरी स्क्यान चलाउनु हुँदैन। उत्पादन।
5. कमजोरी पत्ता लगाउने गुणस्तर। स्क्यानरहरूले सामान्यतया पेलोडहरूको निश्चित एरे प्रयोग गर्छन् र तिनीहरूको ज्ञात अनुप्रयोग व्यवहारमा फिट नहुने जोखिमलाई सजिलै मिस गर्न सक्छन्।
6. स्क्यानरले अनुप्रयोगको कार्यहरू बुझ्दैन। "इन्टरनेट बैंक", "भुक्तानी", "टिप्पणी" के हो भनेर स्क्यानरहरू आफैलाई थाहा छैन। तिनीहरूका लागि, त्यहाँ केवल लिङ्कहरू र प्यारामिटरहरू छन्, त्यसैले सम्भावित व्यापार तर्क कमजोरीहरूको एक विशाल तह पूर्ण रूपमा खुला रहन्छ, तिनीहरूले एक डबल राइट-अफ गर्न, आईडी द्वारा अन्य व्यक्तिहरूको डेटा झलक गर्ने वा राउन्डिङ मार्फत ब्यालेन्स वाइन्ड अप गर्ने अनुमान गर्दैनन्।
7. स्क्यानर द्वारा पृष्ठ अर्थशास्त्र को गलतफहमी। स्क्यानरहरूले FAQ पढ्न सक्दैनन्, क्याप्चाहरू चिन्न सक्दैनन्, तिनीहरू आफैले कसरी दर्ता गर्ने र त्यसपछि पुन: लगइन गर्ने, तपाईंले "लगआउट" मा क्लिक गर्न सक्नुहुन्न, र प्यारामिटर मानहरू परिवर्तन गर्दा अनुरोधहरू कसरी साइन गर्ने भन्ने बारे आफै अनुमान गर्दैनन्। नतिजाको रूपमा, अधिकांश अनुप्रयोगहरू स्क्यान नगरिएको हुन सक्छ।

स्रोत कोड स्क्यानिङ समस्याहरू

1. गलत सकारात्मक। स्थिर विश्लेषण एक जटिल कार्य हो जसमा धेरै सम्झौताहरू समावेश छन्। प्रायः तपाईले शुद्धता त्याग्नु पर्छ, र महँगो उद्यम स्क्यानरहरूले पनि ठूलो संख्यामा झूटा सकारात्मकहरू दिन्छन्।
2. कार्यान्वयनमा कठिनाई । स्थिर विश्लेषणको शुद्धता र पूर्णता बढाउन, स्क्यानिङ नियमहरू परिष्कृत गर्न आवश्यक छ, र यी नियमहरू लेख्न धेरै समय लाग्न सक्छ। कहिलेकाहीँ कुनै प्रकारको बगको साथ कोडमा सबै ठाउँहरू फेला पार्न र त्यस्ता केसहरू पत्ता लगाउन नियम लेख्नु भन्दा तिनीहरूलाई ठीक गर्न सजिलो हुन्छ।
3. निर्भरता समर्थनको अभाव। ठूला परियोजनाहरू धेरै संख्यामा पुस्तकालयहरू र फ्रेमवर्कहरूमा निर्भर हुन्छन् जसले प्रोग्रामिङ भाषाको क्षमता विस्तार गर्दछ। यदि स्क्यानरको ज्ञान आधारमा यी ढाँचाहरूमा खतरनाक ठाउँहरू ("डूब") बारे कुनै जानकारी छैन भने, यो एक अन्धो ठाउँ हुनेछ, र स्क्यानरले कोड पनि बुझ्दैन।
4. स्क्यान अवधि। एल्गोरिदमको सन्दर्भमा कोडमा कमजोरीहरू फेला पार्नु पनि गाह्रो काम हो। त्यसकारण, प्रक्रिया ढिलो हुन सक्छ र महत्त्वपूर्ण कम्प्युटिङ स्रोतहरू चाहिन्छ।
5. कम कभरेज। स्रोतको खपत र स्क्यान अवधिको बावजुद, SAST उपकरण विकासकर्ताहरूले अझै पनि सम्झौताको सहारा लिनु पर्छ र कार्यक्रममा हुन सक्ने सबै राज्यहरूको विश्लेषण गर्नुपर्छ।
6. प्रजनन क्षमता खोज्दै। विशिष्ट रेखा र कल स्ट्याकमा संकेत गर्नु जसले जोखिममा पुर्‍याउँछ, तर वास्तवमा, प्रायः स्क्यानरले बाह्य भेद्यता जाँच गर्न पर्याप्त जानकारी प्रदान गर्दैन। आखिर, दोष मृत कोडमा पनि हुन सक्छ, जुन आक्रमणकारीको लागि पहुँचयोग्य छैन।

पूर्वाधार स्क्यानिङ समस्याहरू

1. अपर्याप्त सूची। ठूला पूर्वाधारहरूमा, विशेष गरी भौगोलिक रूपमा छुट्याइएकाहरूमा, कुन होस्टहरू स्क्यान गर्ने भनेर पत्ता लगाउन प्राय: गाह्रो हुन्छ। अर्को शब्दमा, स्क्यानिङको कार्य सम्पत्ति व्यवस्थापनको कार्यसँग नजिकको सम्बन्ध छ।
2. खराब प्राथमिकता। सञ्जाल स्क्यानरहरूले प्रायः त्रुटिहरू सहित धेरै परिणामहरू उत्पादन गर्छन् जुन व्यवहारमा शोषणयोग्य हुँदैनन्, तर औपचारिक रूपमा तिनीहरूको जोखिमको स्तर उच्च हुन्छ। उपभोक्ताले एक रिपोर्ट प्राप्त गर्दछ जुन व्याख्या गर्न गाह्रो छ, र यो स्पष्ट छैन कि पहिले के सुधार गर्न आवश्यक छ
3. खराब सिफारिसहरू। स्क्यानर ज्ञान आधारमा प्रायः कमजोरी र यसलाई कसरी समाधान गर्ने भन्ने बारेमा धेरै सामान्य जानकारी समावेश हुन्छ, त्यसैले प्रशासकहरूले आफैंलाई गुगलसँग हात हाल्नु पर्छ। स्थिति ह्वाइटबक्स स्क्यानरहरूसँग थोरै राम्रो छ, जसले फिक्स गर्नको लागि विशेष आदेश जारी गर्न सक्छ
4. हस्तनिर्मित। पूर्वाधारहरूमा धेरै नोडहरू हुन सक्छन्, जसको मतलब त्यहाँ सम्भावित रूपमा धेरै त्रुटिहरू छन्, जसमा प्रत्येक पुनरावृत्तिमा म्यानुअल रूपमा प्रतिवेदनहरू पार्स र विश्लेषण गर्नुपर्छ।
5. खराब कभरेज। पूर्वाधार स्क्यानिङको गुणस्तर सीधै कमजोरीहरू र सफ्टवेयर संस्करणहरूको बारेमा ज्ञान आधारको आकारमा निर्भर गर्दछ। जसमा, बाहिर जान्छ, बजार नेताहरूसँग पनि व्यापक ज्ञानको आधार छैन, र नि: शुल्क समाधानहरूको डाटाबेसमा धेरै जानकारी छ जुन नेताहरूसँग छैन।
6. प्याचिङको साथ समस्याहरू। प्रायः, प्याचिङ पूर्वाधार कमजोरी प्याकेज अद्यावधिक वा कन्फिगरेसन फाइल परिवर्तन गर्दैछ। यहाँ ठूलो समस्या यो हो कि प्रणाली, विशेष गरी विरासत एक, अपडेटको परिणामको रूपमा अप्रत्याशित रूपमा व्यवहार गर्न सक्छ। वास्तवमा, तपाईंले उत्पादनमा प्रत्यक्ष पूर्वाधारमा एकीकरण परीक्षणहरू सञ्चालन गर्नुपर्नेछ।

दृष्टिकोणहरू

कसरी हुन?
म उदाहरणहरू र निम्न भागहरूमा यी धेरै समस्याहरूसँग कसरी व्यवहार गर्ने बारे थप विवरणहरूमा जानेछु, तर अहिलेको लागि म तपाईंले काम गर्न सक्ने मुख्य क्षेत्रहरू संकेत गर्नेछु:

1. विभिन्न स्क्यानिङ उपकरणहरूको एकत्रीकरण। धेरै स्क्यानरहरूको सही प्रयोगको साथ, ज्ञानको आधारमा उल्लेखनीय वृद्धि र पहिचानको गुणस्तर हासिल गर्न सकिन्छ। तपाईंले व्यक्तिगत रूपमा चल्ने सबै स्क्यानरहरूको योगफलभन्दा पनि बढी भेद्यताहरू फेला पार्न सक्नुहुन्छ, जबकि तपाईंले जोखिमको स्तरलाई अझ सही रूपमा मूल्याङ्कन गर्न सक्नुहुन्छ र थप सिफारिसहरू गर्न सक्नुहुन्छ।
2. SAST र DAST एकीकरण। तिनीहरू बीच जानकारी साझा गरेर DAST कभरेज र SAST सटीकता बढाउन सम्भव छ। स्रोतबाट तपाईंले अवस्थित रुटहरूको बारेमा जानकारी प्राप्त गर्न सक्नुहुन्छ, र DAST को मद्दतले तपाईंले जोखिम बाहिरबाट देखिने छ कि छैन भनेर जाँच गर्न सक्नुहुन्छ।
3. मेसिन लर्निङ™। सन् २०१५ मा म बताए (र अधिक) स्क्यानरहरूलाई ह्याकरको अन्तर्ज्ञान दिन र तिनीहरूलाई गति दिन तथ्याङ्कहरू प्रयोग गर्ने बारे। यो निश्चित रूपमा भविष्यमा स्वचालित सुरक्षा विश्लेषणको विकासको लागि खाना हो।
4. Autotests र OpenAPI संग IAST एकीकरण। CI/CD-पाइपलाइन भित्र, HTTP प्रोक्सीहरू र HTTP मा काम गर्ने कार्यात्मक परीक्षणहरूको रूपमा काम गर्ने उपकरणहरूमा आधारित स्क्यानिङ प्रक्रिया सिर्जना गर्न सम्भव छ। OpenAPI/Swagger परीक्षण र अनुबंधहरूले स्क्यानरलाई डाटा प्रवाहको बारेमा छुटेको जानकारी दिनेछ, विभिन्न राज्यहरूमा अनुप्रयोग स्क्यान गर्न सम्भव बनाउँदछ।
5. सही कन्फिगरेसन। प्रत्येक अनुप्रयोग र पूर्वाधारको लागि, तपाईंले इन्टरफेसहरूको संख्या र प्रकृति, प्रयोग गरिएका प्रविधिहरूलाई ध्यानमा राख्दै उपयुक्त स्क्यानिङ प्रोफाइल सिर्जना गर्न आवश्यक छ।
6. स्क्यानर अनुकूलन। प्रायः, स्क्यानर परिमार्जन नगरी अनुप्रयोग स्क्यान गर्न सकिँदैन। एउटा उदाहरण भनेको भुक्तानी गेटवे हो जहाँ प्रत्येक अनुरोधमा हस्ताक्षर हुनुपर्छ। गेटवे प्रोटोकलमा कनेक्टर नलिइकन, स्क्यानरहरूले गलत हस्ताक्षरको साथ अनुरोधहरूलाई बेवास्ता गर्ने छन्। यो पनि एक विशेष प्रकार को त्रुटिहरु को लागी विशेष स्क्यानर लेख्न आवश्यक छ, जस्तै असुरक्षित प्रत्यक्ष वस्तु सन्दर्भ
7. जोखिम व्यवस्थापन। विभिन्न स्क्यानरहरूको प्रयोग र सम्पत्ति व्यवस्थापन र खतरा व्यवस्थापन जस्ता बाह्य प्रणालीहरूसँग एकीकरणले जोखिमको स्तर मूल्याङ्कन गर्न धेरै प्यारामिटरहरू प्रयोग गर्न अनुमति दिनेछ, जसले गर्दा व्यवस्थापनले विकास वा पूर्वाधारको वर्तमान सुरक्षा अवस्थाको पर्याप्त चित्र प्राप्त गर्न सक्छ।

सम्पर्कमा रहनुहोस् र भेद्यता स्क्यानिङलाई अवरोध गरौं!

स्रोत: www.habr.com