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

क्या एल्गोरिदम द्वारा, किस नियम से? या यह सब कुछ है "और मुझे पता है कि मीम क्या है!" इस मामले में, विधि कहीं भी निरपेक्ष मामले के रूप में कुछ भी वर्णन नहीं करती है - मैंने सोचा, कहीं न कहीं।

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

---

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

विशेषज्ञ तरीके

विशेषज्ञ विधियां इस तथ्य पर आधारित हैं कि सूचना प्रणाली अधिक या कम प्रसिद्ध पैटर्न के अनुसार बनाई गई हैं। आर्किटेक्चर पैटर्न, डिजाइन पैटर्न, कोड हैं। डेवलपर्स प्रसिद्ध सुरक्षा उपकरणों और तकनीकों का उपयोग करते हैं। कार्यक्रम प्रसिद्ध प्रोग्रामिंग भाषाओं में लिखे गए हैं, सामान्य ऑपरेटिंग सिस्टम के नियंत्रण में काम करते हैं, सुलभ पुस्तकालयों का उपयोग करते हैं, और उपलब्ध सेवाओं का उपयोग करते हैं। और इनमें से प्रत्येक पैटर्न का उपयोग कुछ कमजोरियों के उभरने की संभावना को खोलता है।
इसलिए, उदाहरण के लिए, यदि प्रोग्राम C, C ++ में लिखा गया है, तो आप इसमें "शोषक" बफर अतिप्रवाह खोजने की कोशिश कर सकते हैं। यदि प्रोग्राम की अनुरोध भाषा काफी जटिल है, तो यह एपीआई दुरुपयोग के तरीकों का उपयोग करके हमला करने के लिए असुरक्षित हो सकता है। यदि प्रोग्राम उपयोगकर्ता को प्रमाणित करने के लिए पासवर्ड का उपयोग करता है, तो इसे लेने का मौका है। DBMS प्रोग्राम अक्सर SQL इंजेक्शन की चपेट में आते हैं। यह सूची, जैसा कि आप अनुमान लगा सकते हैं, बहुत बड़ी है।
एक अधिक जटिल प्रणाली अपने घटक भागों में विघटित हो जाती है। अगला, इन भागों और उनकी बातचीत का विश्लेषण किया जाता है।
इसलिए सर्वर और क्लाइंट भागों से युक्त प्रणाली में, आपको सर्वर, क्लाइंट और उनके बीच बातचीत के प्रोटोकॉल का विश्लेषण करने की आवश्यकता होती है। इस मामले में, अलग-अलग हिस्सों को घटकों में अलग करना उपयोगी हो सकता है। उदाहरण के लिए, सर्वर भाग में अक्सर एक डीबीएमएस और एक एप्लिकेशन सर्वर होता है। बदले में, एप्लिकेशन सर्वर को ऑपरेटिंग सिस्टम में कई प्रक्रियाओं के रूप में लागू किया जा सकता है; प्रत्येक प्रक्रिया - एक या दूसरे पुस्तकालय का उपयोग करें।
दरअसल, तकनीक किसी प्रोग्राम या सिस्टम के इंटरेक्टिंग पार्ट्स के रूप में कुछ प्रतिनिधित्व खोजने के लिए नीचे आती है। यह दृश्य हमें उपलब्ध ऐतिहासिक जानकारी के आधार पर, प्रत्येक भाग की भेद्यता और उनकी सहभागिता से जुड़ी कमजोरियों का विश्लेषण करने की अनुमति देता है।
विशेषज्ञ दृष्टिकोण का एक अच्छा उदाहरण Microsoft द्वारा विकसित और उपयोग की जाने वाली विधि है। विधि, विशेष रूप से, "थ्रोटमॉडलिंग" [ 1 ] पुस्तक में वर्णित है। यह कार्यक्रम की वास्तुकला का विश्लेषण करने के लिए सूचना प्रवाह आरेखों का उपयोग करता है; परिणामों का प्रतिनिधित्व करने के लिए हमले के पेड़ों का उपयोग किया जाता है।
इस प्रकार, विशेषज्ञ विधियाँ किसी विशेषज्ञ की योग्यता के आधार पर एक कार्यक्रम को विघटित करने और विभिन्न प्रकार के कार्यक्रमों और प्रोटोकॉल की कमजोरियों के अपने ज्ञान पर आधारित होती हैं।

औपचारिक तरीके

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

सरल उदाहरण है

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



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

मॉडल मान्यताओं

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

निष्कर्ष

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

टिप्पणी

* यदि आप अपेक्षाकृत सुरक्षा के बिना सामान्य रूप से औपचारिक दृष्टिकोण में रुचि रखते हैं, तो आप "औपचारिक तरीकों को समझना" पुस्तक को पढ़ने में दिलचस्पी ले सकते हैं [ 2 ]।
एक और किताब है कंप्यूटर सिक्योरिटी। कला और विज्ञान ”[ 3 ] में सूचना सुरक्षा में गणितीय मॉडल के बारे में बहुत सारी जानकारी शामिल है, जिसमें सॉफ्टवेयर सुरक्षा का विश्लेषण करने के लिए औपचारिक तरीकों के लिए समर्पित एक अलग अध्याय शामिल है।

साहित्य

1. फ्रैंक स्वेदस्की, विंडो स्नाइडर "थ्रेट मॉडलिंग", माइक्रोसॉफ्ट प्रेस 2004, आईएसबीएन 978-0-73569999-3
2. जीन फ्रेंकोइस मोनिन, मिशल जी। हिकी (संपादक) "अंडरस्टैंडिंग फॉर्मल मेथड्स", स्प्रिंगर-वर्लग 2003, आईएसबीएन 1-85233-247-6
3. मैट बिशप “कंप्यूटर सुरक्षा। कला और विज्ञान ”, एडिसन-वेस्ले 2003, आईएसबीएन 0-201-44099-7