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