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

कहाँ वर्णित है

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

उपयोग मामलों का विस्तार करना

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

सरलतम प्रणाली

विधि से परिचित होने के लिए, आइए एक अत्यंत सरलीकृत उदाहरण देखें।
मान लीजिए हमारे पास एक कार्यक्रम है जो एक निश्चित दस्तावेज़ पढ़ने के लिए संभव बनाता है।

जाहिर है, अनधिकृत सहित कोई भी, उपयोगकर्ता समान कार्यक्षमता का उपयोग करके उसी दस्तावेज़ को पढ़ सकता है। इस तथ्य का विवरण आरेख में जोड़ें।

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

परिणामी परियोजना का विश्लेषण करने के बाद, हम देखेंगे कि पासवर्ड का चयन करके प्रमाणीकरण को बायपास किया जा सकता है। इस तथ्य को चार्ट में जोड़ें।

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

प्राप्त परियोजना के विश्लेषण से पता चलता है कि घुसपैठिया, संभवतः पहले से अलग था, एक अधिकृत उपयोगकर्ता के काम को अवरुद्ध करने में सक्षम था।

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

इस उदाहरण में क्या गायब है

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

• अपने लक्ष्य तक पहुँचता है;
• सिस्टम के मालिक को नुकसान पहुँचाता है।

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

फायदे और नुकसान

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

निष्कर्ष

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

साहित्य

1. जी। सिंद्रे और एएल ओपडाहल, "इस्किटिंग सेक्रटरी रिक्वायरमेंट बाय मिस्यूज केसेस", प्रोक। टूल्स प्रशांत 2000, नवंबर 2000।
2. जी। सिंद्रे और एएल ओपडहल, " मिसयूज केस केस का विवरण" इंटरनेशनल वर्कशॉप रिक्वायरमेंट्स इंजीनियरिंग की कार्यवाही: फाउंडेशन फॉर सॉफ्टवेयर क्वालिटी (REFSQ 2001), 2001।
3. जी। सिंद्रे, एएल ओपडाहल, और जीएफ ब्रेविक, " मिसयूज मामलों के लिए एक संरचना तंत्र के रूप में सामान्यीकरण / विशेषज्ञता" सूचना सुरक्षा के लिए आवश्यकताएँ इंजीनियरिंग पर संगोष्ठी की कार्यवाही, 2002।
4. जी। सिंद्रे और एएल ओपडाहल, " मिसयूज केसेस के साथ सिक्योरिटी रिक्वायरमेंट्स" आवश्यकताएँ इंजीनियरिंग जर्नल, 10 (1): 34-44, 2005।
5. I. अलेक्जेंडर, "उपयोग और दुरुपयोग के मामलों के साथ संघर्ष के लक्ष्यों की प्रतिरूप मॉडलिंग" , आवश्यकताएँ इंजीनियरिंग पर आठवीं अंतर्राष्ट्रीय कार्यशाला की कार्यवाही: सॉफ्टवेयर गुणवत्ता के लिए फाउंडेशन, सितंबर 2002
6. I. अलेक्जेंडर, "ट्रेड-ऑफ विश्लेषण में दुरुपयोग के मामलों का प्रारंभिक औद्योगिक अनुभव" , IEEE संयुक्त अंतर्राष्ट्रीय आवश्यकताओं की कार्यवाही, इंजीनियरिंग सम्मेलन, सितंबर 2002
7. I. अलेक्जेंडर, "दुरुपयोग के मामले: शत्रुतापूर्ण इरादे के साथ मामलों का उपयोग करें" IEEE सॉफ्टवेयर, 2003