ایک مفید خطرے کا ماڈل وضاحت کرتا ہے کہ آپ کیا تحفظ دیتے ہیں، کون یا کیا اس پر اثر ڈال سکتا ہے، اعتماد کہاں بدلتا ہے اور آپ اہم ترین خطرات کو کیسے کم اور آزمائیں گے۔ عمومی ٹولز کی فہرست کے بجائے اصل پروجیکٹ سے شروع کریں۔
اتنی چھوٹی حد متعین کریں کہ اس پر استدلال ممکن ہو
ایک کام کرنے والی سروس سے شروع کریں: کسٹمر پورٹل، اشاعتی سائٹ یا اندرونی ایپلیکیشن۔ وہ اجزاء لکھیں جو آپ چلاتے ہیں اور وہ بیرونی نظام جن پر آپ انحصار کرتے ہیں۔ خطرے کے ماڈل کو مفروضات واضح کرنے چاہئیں، یہ تجویز نہیں کہ ہر ممکنہ حملہ حل ہو گیا ہے۔ پہلا ورژن اتنا چھوٹا رکھیں کہ ایپلیکیشن تعینات کرنے والے اسے الگ کنسلٹنٹ کے ڈایاگرام کی تشریح کے بغیر سمجھا سکیں۔
قیمتی نتائج اور اثاثوں کی فہرست بنائیں۔ ان میں کسٹمر ڈیٹا، انتظامی رسائی، ادائیگی کی حالت، شائع شدہ مواد اور سروس بحال کرنے کی صلاحیت شامل ہو سکتی ہے۔ دستیابی بھی ایک اثاثہ ہو سکتی ہے چاہے معلومات عوامی ہوں۔ فیصلہ کریں کہ کون سی ناکامیاں تکلیف دہ ہوں گی اور کون سی لوگوں یا تنظیم کو نقصان پہنچائیں گی۔ یہ فرق کنٹرولز کو ترجیح دینے میں مدد کرتا ہے، بجائے ہر انتباہ کو یکساں سمجھنے کے۔
وہ مقامات بنائیں جہاں اعتماد بدلتا ہے
OWASP کی خطرے کے ماڈل کی رہنمائی ڈیزائن کو سمجھنے کے قابل بنانے کے لیے ڈیٹا کے بہاؤ اور اعتماد کی حدود استعمال کرتی ہے۔ ایک چھوٹی ہوسٹڈ ایپلیکیشن کے لیے براؤزر، ویب عمل، ڈیٹا بیس، منتظم، بیک اپ منزل اور بیرونی انضمام بنائیں۔ ان کے درمیان منتقل ہونے والی معلومات نشان زد کریں۔ غیر قابلِ اعتماد کلائنٹ سے مراعات یافتہ سرور عمل میں جانے والی درخواست واضح توثیق اور اجازت کی مستحق ہے۔
یہ فرض نہ کریں کہ ایک ہی مشین کے اندر ہونے سے ہر جزو یکساں قابلِ اعتماد ہے۔ عوامی اپ لوڈ عمل کو ڈیٹا بیس انتظام جیسی اجازتیں نہیں ہونی چاہئیں۔ بیک اپ کام کو پڑھنے کی رسائی درکار ہو سکتی ہے مگر لائیو ایپلیکیشن ریکارڈز تبدیل کرنے کی صلاحیت نہیں۔ ان کرداروں کو الگ کرنا سمجھوتے کا شکار جزو کے اثر کو قابو میں رکھنا اور مطلوبہ اجازتوں کا جائزہ آسان بناتا ہے۔
ٹھوس ناکامی کے منظر نامے منتخب کریں
ڈیزائن کو چیلنج کرنے کے لیے چند قابلِ فہم واقعات استعمال کریں۔ حملہ آور منتظم کا پاس ورڈ چرا لیتا ہے؛ ایک صارف دوسرے صارف کا ریکارڈ طلب کرتا ہے؛ ایک اپ لوڈ ڈسک بھر دیتا ہے؛ ایک تعیناتی ترتیب کی فائل بے نقاب کرتی ہے؛ ایک بحالی نقل بحال نہیں ہو سکتی۔ ابتدائی حالت، متاثرہ جزو اور نتیجہ بیان کریں۔ مخصوص منظر نامہ سیکیورٹی بہتر بنانے کی وسیع ہدایت سے زیادہ آسانی سے آزمایا جا سکتا ہے۔
بیرونی دراندازی کے ساتھ ساتھ غلطیاں اور جائز ورک فلو کا غلط استعمال بھی شامل کریں۔ دوبارہ کوشش دو قیمتی عمل پیدا کر سکتی ہے، یا دو درخواستیں ایک ہی شے کو تبدیل کرنے کی دوڑ لگا سکتی ہیں۔ OWASP کی بزنس لاجک رہنمائی ان عمل کے مفروضوں کو نمایاں کرتی ہے۔ جانچیں کہ کس کو ورک فلو کو اگلی حالت میں لے جانے کی اجازت ہے اور کیا درخواست دہرانے یا ترتیب بدلنے سے نتیجہ غیر متوقع طور پر بدلتا ہے۔
| منظر نامہ | تحقیق کے لیے کنٹرول | جمع کرنے کے لیے ثبوت |
|---|---|---|
| چوری شدہ انتظامی اسناد | محدود رسائی اور جہاں ممکن ہو دوسرا عنصر | غیر مجاز لاگ ان مکمل نہیں ہو سکتا |
| دوسرے صارف کی شے طلب کی گئی | سرور کی طرف سے شے کی اجازت | الگ تھلگ ٹیسٹ مسترد نتیجہ دیتا ہے |
| اپ لوڈز سے ڈسک بھر گئی | سائز، کوٹہ اور برقراری کے کنٹرول | سروس کی ناکامی سے پہلے حد نافذ ہوتی ہے |
| ورک فلو کی نقل درخواست | Idempotency اور لین دین کی حدود | دہرائی گئی درخواست ایک نتیجہ پیدا کرتی ہے |
اثر اور قابلِ اعتبار راستے کی بنیاد پر ترجیح دیں
ہر منظر نامے کے لیے اس کا ممکنہ اثر اور اس کے وقوع کے لیے درکار شرائط ریکارڈ کریں۔ یہ ظاہر کرنے سے بچیں کہ اندازہ لگایا گیا عددی اسکور درست امکان ہے۔ آپ پھر بھی انٹرنیٹ پر بے نقاب کمزور پاس ورڈ کو انتہائی مشروط مقامی واقعے سے الگ کر سکتے ہیں۔ اہم خطرات کو ایک مالک اور عملی اگلا قدم تفویض کریں تاکہ ماڈل ایسا کام پیدا کرے جو کوئی واقعی مکمل کر سکے۔
ایپلیکیشن کے سمجھوتے کے ساتھ ساتھ معلومات کے لائف سائیکل پر بھی غور کریں۔ تشخیصی ایکسپورٹ عام آپریشن کے دوران غیر ضروری ڈیٹا افشا کر سکتی ہے۔ محفوظ رکھا گیا اکاؤنٹ فیلڈ اپنے مقصد کے ختم ہونے کے بہت بعد بھی نمائش پیدا کر سکتا ہے۔ اس لیے پرائیویسی جائزہ معلومات ہٹا سکتا ہے یا برقراری کم کر سکتا ہے، جبکہ سیکیورٹی جائزہ باقی ماندہ تک رسائی محدود کرتا ہے۔ جب یہ تبدیلیاں پروجیکٹ کی حفاظت کریں تو دونوں ماڈل میں شامل ہونی چاہئیں۔
مجاز ماحول میں کنٹرولز کی آزمائش کریں
نمائندہ اجازتوں اور من گھڑت ریکارڈز کے ساتھ اسٹیجنگ ماحول بنائیں۔ مسترد شدہ رسائی، درخواست کی حدود، ورک فلو دوبارہ کوششوں اور بحالی کی جانچ کریں۔ جب مصنوعی ڈیٹا رویے کا مظاہرہ کر سکتا ہو تو حقیقی کسٹمر ڈیٹا استعمال نہ کریں۔ مقصد کنٹرول کی تصدیق کرنا ہے، متاثر کن حملے کی ٹریفک پیدا کرنا نہیں۔ صرف ان سسٹمز کے اندر رہیں جو آپ کے ملکیت میں ہیں یا جن کا جائزہ لینے کے لیے آپ کو واضح طور پر اجازت دی گئی ہے۔
ریکارڈ کریں کہ کیا پاس ہوا، کیا ناکام ہوا اور کیا ابھی تک نامعلوم ہے۔ اسکینر کا نتیجہ شواہد میں حصہ ڈال سکتا ہے لیکن یہ ایپلیکیشن کے کاروباری قواعد کے ٹیسٹ کا متبادل نہیں ہے۔ اسی طرح، نیٹ ورک تحفظ کا آپشن آبجیکٹ کی اجازت یا خفیہ فائل ہینڈلنگ کی تصدیق نہیں کرتا۔ مفید نتائج کو منظر نامے کے ساتھ منسلک کریں تاکہ مستقبل کے دیکھ بھال کرنے والے سمجھ سکیں کہ کوئی خاص کنٹرول کیوں موجود ہے۔
ماڈل کو تبدیلی سے جڑا رکھیں
جب آپ کوئی انٹیگریشن شامل کریں، نیا اینڈ پوائنٹ ظاہر کریں، کوئی استحقاق تبدیل کریں یا ڈیٹا کسی دوسری منزل پر منتقل کریں تو متعلقہ حصوں کا جائزہ لیں۔ معمولی متن کی ترمیم کے لیے آپ کو پورے آرکیٹیکچر کو دوبارہ بنانے کی ضرورت نہیں۔ محرک رسائی، معلومات یا سسٹم کے رویے کے بارے میں تبدیل شدہ مفروضہ ہے۔ ماڈل کو تعیناتی اور بحالی کی دستاویزات کے ساتھ رکھیں، بجائے اس کے کہ اسے ایک بار کے ورکشاپ کے آؤٹ پٹ کے طور پر چھوڑ دیں۔
SwissOctet انفراسٹرکچر کے انتخاب کی فہرست فراہم کرتا ہے، مکمل ایپلیکیشن خطرہ ماڈل نہیں۔ وہ کنفیگریشن اور آپشنز منتخب کریں جو آپ کے کنٹرولز کی حمایت کرتے ہیں، پھر آپ جو تعیناتی بناتے ہیں اس کی تصدیق کریں۔ آزمودہ اقدامات کے ساتھ چھوٹا، برقرار رکھا گیا ماڈل سیکیورٹی مصنوعات کے بڑے مجموعے سے زیادہ مفید ہے جس میں ان خطرات کی واضح وضاحت نہ ہو جن کا وہ ازالہ کرتے ہیں۔
آپ کی عملی چیک لسٹ۔
- اثاثے اور ناکامی کے نتائج کی فہرست بنائیں۔
- ڈیٹا کے بہاؤ اور اعتماد کی حدود کھینچیں۔
- مخصوص دراندازی، غلطی اور ورک فلو کے منظرنامے منتخب کریں۔
- اہم خطرات کے لیے کنٹرولز اور ذمہ داران تفویض کریں۔
- مجاز ماحول میں مصنوعی ڈیٹا کے ساتھ جانچ کریں۔
- جب کوئی متعلقہ مفروضہ تبدیل ہو تو ماڈل کا جائزہ لیں۔
وہ تفصیلات جو اہم ہیں۔
کیا شروع کرنے کے لیے مجھے رسمی فریم ورک کی ضرورت ہے؟+
نہیں۔ ایک چھوٹا خاکہ اور منظرناموں کا دستاویزی مجموعہ مفید ہو سکتا ہے۔ فریم ورک اس بات کو یقینی بنانے میں مدد کرتا ہے کہ آپ خطرات کا مستقل جائزہ لیں۔
کیا کمزوری اسکینر خطرہ ماڈلنگ کا متبادل ہے؟+
نہیں۔ اسکینر تکنیکی کمزوریاں تلاش کر سکتے ہیں، جبکہ خطرہ ماڈل ڈیزائن کے مفروضوں، اجازتوں اور کاروباری ورک فلوز کا بھی جائزہ لیتا ہے۔
مجھے ماڈل کتنی بار اپ ڈیٹ کرنا چاہیے؟+
جب ڈیٹا کے بہاؤ، انٹیگریشنز، استحقاقات یا ظاہر کردہ فعالیت تبدیل ہوں تو متاثرہ حصوں کو اپ ڈیٹ کریں، اور غیر حل شدہ خطرات کا باقاعدگی سے جائزہ لیں۔
ماخذ پر جائیں۔
یہ حوالہ جات اس گائیڈ میں تکنیکی تصورات کی حمایت کرتے ہیں۔ پروڈکشن سسٹم تبدیل کرنے سے پہلے موجودہ دستاویزات کی پیروی کریں۔
- OWASP: تھریٹ ماڈلنگ چیٹ شیٹ cheatsheetseries.owasp.org
- OWASP: عملی طور پر تھریٹ ماڈلنگ devguide.owasp.org
- OWASP: بزنس لاجک سیکیورٹی cheatsheetseries.owasp.org
SwissOctet کی طرف سے ادارتی رہنمائی۔ مثالیں مثالی ہیں۔ سروس کی تفصیلات، دستیاب اختیارات اور معاہدے کی شرائط الگ سے تصدیق شدہ ہونی چاہئیں۔