یک پرونده واقعی برای جلسه مدل‌سازی
تیمی را در نظر بگیرید که می‌خواهد امکان بارگذاری رسید خرید را به برنامه پشتیبانی اضافه کند. مشتری فایل می‌فرستد، سرویس وب آن را در فضای ذخیره‌سازی می‌گذارد و کارشناس پشتیبانی از طریق پیوندی موقت تصویر را می‌بیند. پیش از نوشتن کد باید معلوم شود چه کسی می‌تواند پیوند بسازد، رسید چه مدت باقی می‌ماند و اگر درخواست یک مشتری برای رسید مشتری دیگر تکرار شود چه اتفاقی می‌افتد. OWASP Threat Dragon به تیم کمک می‌کند مسیر داده را ترسیم کند و تهدید، دلیل، اقدام اصلاحی و وضعیت بررسی را به عنصر مرتبط وصل کند.
برای آغاز جلسه، یک نفر از تیم توسعه مسیر واقعی درخواست را توضیح دهد و مسئول پشتیبانی نحوه استفاده روزانه را شرح دهد. ممکن است طراح تصور کند پیوند فقط در صفحه داخلی دیده می‌شود، در حالی که کارشناس برای سرعت کار آن را در پیام‌رسان کپی می‌کند. چنین تفاوتی بیش از افزودن چند نماد فنی به نمودار ارزش دارد. محدوده جلسه را یک جریان کامل و قابل بررسی انتخاب کنید. در مثال رسید، از لحظه ارسال مشتری تا حذف تصویر و پایان اعتبار پیوند را دنبال کنید. سایر بخش‌های سامانه تنها تا جایی وارد مدل شوند که بر این جریان اثر می‌گذارند.
انتخاب نسخه و محل نگه‌داری مدل
پروژه نسخه وب و رومیزی ارائه می‌دهد. در توضیح رسمی، نسخه رومیزی پرونده‌های مدل را در فایل‌سیستم محلی نگه می‌دارد. نسخه وب می‌تواند برای کار با فایل محلی یا مخازن بیرونی پیکربندی شود. انتخاب بین آن‌ها به روش همکاری و حساسیت معماری بستگی دارد. برای کارگاهی با چند نفر در یک اتاق، پرونده محلی ممکن است کافی باشد. برای تیمی که مدل را همراه تغییرات محصول بازبینی می‌کند، ذخیره در مخزن دارای کنترل دسترسی و تاریخچه می‌تواند ردیابی تصمیم‌ها را آسان‌تر کند. پیش از استفاده از مخزن، مجوز برنامه و دامنه دسترسی را بررسی کنید.
مدل تهدید اغلب مسیرهای حساس، فرض‌های اعتماد و ضعف‌های باز را آشکار می‌کند. لازم نیست برای توصیف خطر، نام کاربری واقعی، نشانی داخلی کامل یا توکن تولید را وارد فایل کنید. در مثال رسید از نام‌های نقش و مسیر منطقی استفاده کنید تا بحث روشن بماند و فایل به محل نگه‌داری داده مشتری تبدیل نشود. اگر از نسخه نمایشی عمومی برای آشنایی استفاده می‌کنید، یک مدل ساختگی انتخاب کنید. پرونده واقعی باید در محیطی ذخیره شود که مالک آن، روش نسخه‌برداری و سیاست بازبینی مشخص است.
رسم نمودار با واژگان ساده
Threat Dragon برای بازیگر، فرایند، مخزن داده، جریان و مرز اعتماد شکل‌های قابل انتخاب دارد. در مثال ما مشتری یک بازیگر است، سرویس دریافت رسید یک فرایند است و مخزن تصویر محل نگه‌داری داده است. پیکان میان مشتری و سرویس را با نام اطلاعاتی که واقعاً جابه‌جا می‌شود مشخص کنید. «ارسال رسید و شناسه پرونده» از عنوان کلی «درخواست» روشن‌تر است. اگر پاسخ حاوی شناسه فایل یا پیوند موقت است، مسیر پاسخ را نیز جدا نشان دهید تا تیم بتواند محرمانگی و اختیار استفاده از آن را بررسی کند.
یک پیکان دوطرفه ممکن است برای نقشه کلی کافی باشد، ولی در مدل امنیتی درخواست و پاسخ معمولاً ویژگی‌های متفاوتی دارند. مشتری مجاز است فایل خودش را بفرستد اما نباید اختیار انتخاب مسیر ذخیره‌سازی را به دست آورد. پاسخ سرویس نیز ممکن است اطلاعاتی داشته باشد که مشتری دیگری حق دیدن آن را ندارد. دو جریان جدا کمک می‌کنند تهدید به جهت درست وصل شود. وقتی نمودار شلوغ شد، آن را به چند نمای مربوط به یک هدف تقسیم کنید و نام مؤلفه مشترک را در همه نماها یکسان نگه دارید.
مرز اعتماد از تصمیم مجوز می‌آید
مرز اعتماد را جایی بکشید که فرض درباره هویت، اختیار یا کنترل داده تغییر می‌کند. خط میان اینترنت و شبکه داخلی یک نمونه است، اما تنها مرز نیست. کارشناس پشتیبانی داخل شبکه سازمان هم ممکن است فقط به پرونده‌های منطقه خودش دسترسی داشته باشد. سرویس وب ممکن است با حسابی به مخزن تصویر وصل شود که اختیار بیشتری از مشتری دارد. این تفاوت باید در مدل دیده شود. اگر تمام سامانه داخلی در یک کادر «قابل اعتماد» قرار گیرد، پرسش مهم درباره تغییر سطح اختیار میان سرویس‌ها ناپدید می‌شود.
برای بررسی مرز، از اعضای جلسه بخواهید جمله‌ای قابل آزمون بنویسند. مثلاً سرویس باید پیش از ساخت پیوند بررسی کند پرونده به مشتری درخواست‌کننده تعلق دارد. سپس بپرسید شواهد اجرای این شرط کجاست و اگر شناسه پرونده از مرورگر تغییر کند نتیجه چیست. این روش مرز را از یک خط تزئینی به پرسش طراحی تبدیل می‌کند. در Threat Dragon مرز می‌تواند به شکل کادر یا منحنی ترسیم شود. زیبایی شکل اهمیت کمتری از توافق تیم درباره معنای آن دارد. عنوان و دلیل مرز باید برای خواننده خارج از جلسه هم روشن باشد.
ساختن تهدیدی که توسعه‌دهنده بتواند اصلاح کند
عبارت «امکان دسترسی غیرمجاز» برای برنامه‌نویس بیش از حد کلی است. یک تهدید قابل پیگیری باید عامل، پیش‌شرط، اقدام و پیامد را مشخص کند. در مثال رسید، مشتری واردشده ممکن است شناسه پرونده دیگری را در درخواست ساخت پیوند قرار دهد و به تصویر حاوی اطلاعات شخصی دست یابد، اگر سرویس فقط معتبر بودن نشست را بررسی کند. این توضیح مستقیماً به محل کنترل و آزمون اشاره می‌کند. عنوان کوتاه را برای مرور فهرست نگه دارید و جزئیات را در شرح تهدید و اقدام کاهش خطر ثبت کنید.
ابزار امکان افزودن تهدید به عنصر انتخاب‌شده را فراهم می‌کند و دسته‌بندی‌های مختلف برای هدایت بحث دارد. در نمودار STRIDE می‌توان درباره جعل هویت، دستکاری، انکار، افشا، اختلال خدمت و افزایش اختیار فکر کرد. برای پرسش‌های حریم خصوصی، LINDDUN زاویه متفاوتی می‌دهد. لازم نیست همه دسته‌ها برای هر عنصر تهدید واقعی تولید کنند. اگر هیچ پیش‌شرط معقولی وجود ندارد، دلیل را ثبت کنید و جلو بروید. پیشنهاد خودکار یا دسته‌بندی تنها آغاز گفت‌وگو است. اعتبار نتیجه به شناخت واقعی اعضای تیم از جریان و شرایط استفاده بستگی دارد.
از پیشنهاد به آزمون پذیرش
برای تهدید دسترسی به رسید دیگران، اقدام را به شکل رفتاری بنویسید. سرویس باید مالکیت پرونده را در سمت سرور با هویت نشست مقایسه کند و در صورت ناسازگاری هیچ پیوندی نسازد. سپس دو حساب آزمایشی با پرونده‌های مستقل بسازید و نتیجه درخواست متقاطع را بررسی کنید. آزمون باید علاوه بر پاسخ ظاهری، گزارش دسترسی و نبود پیوند معتبر را نیز بسنجد. اگر تیم فقط متن «کنترل دسترسی اضافه شود» بنویسد، معلوم نیست چه کسی و چگونه می‌تواند تکمیل اقدام را تأیید کند.
تهدید دیگری به مدت اعتبار پیوند مربوط است. حتی اگر مالکیت در زمان صدور درست بررسی شود، پیوندی که برای مدت طولانی کار می‌کند ممکن است پس از پایان نیاز در تاریخچه مرورگر یا پیام باقی بماند. تیم می‌تواند مدت مناسب را با نیاز پشتیبانی تعیین کند، دسترسی به گزارش‌ها را محدود سازد و رفتار پس از انقضا را آزمایش کند. این پرونده از تهدید اختیار در زمان صدور جداست، زیرا کنترل و شواهد متفاوتی دارد. اتصال هر تهدید به جریان درست مانع آن می‌شود که یک اصلاح برای دو مسئله مستقل کافی تصور شود.
بررسی موارد بیرون از دامنه
عنصری که برای خواندن نمودار لازم است اما در اختیار تیم نیست می‌تواند خارج از دامنه مشخص شود. برای نمونه، سامانه خارجی ارسال پیامک ممکن است در این کارگاه بازطراحی نشود. با این حال داده‌ای که از مرز سازمان به آن می‌رسد همچنان باید در مدل دیده شود. در توضیح خروج از دامنه بنویسید مالک بیرونی چه کسی است و کدام فرض درباره آن سرویس دارید. خارج کردن عنصر تنها به دلیل دشوار بودن پاسخ، ریسک را حل نمی‌کند و برای جلسه بعدی یک نقطه کور باقی می‌گذارد.
در ابزار، امکان ایجاد تهدید برای عنصری که خارج از دامنه علامت خورده محدود می‌شود. اگر دکمه افزودن تهدید در دسترس نیست، وضعیت عنصر را بررسی کنید. محدودیت دسته تهدید نیز می‌تواند از نوع نمودار و عنصر ناشی شود. راهنمای رسمی توضیح می‌دهد نوع عمومی دامنه انتخاب بیشتری می‌دهد. پیش از تغییر نوع، ببینید آیا عنصر درست رسم شده است. اگر یک فرایند به اشتباه با شکل بازیگر آمده باشد، اصلاح نماد هم فهم نمودار و هم پیشنهادهای مناسب را بهتر می‌کند.
بازبینی تغییرات و اختلاف نسخه‌ها
مدل را کنار تغییرات معماری به‌روز کنید. فرض کنید تیم تصمیم می‌گیرد تصویر رسید را برای تشخیص تقلب به یک سرویس پردازش بیرونی بفرستد. این تغییر یک جریان تازه، گیرنده تازه و احتمالاً دوره نگه‌داری متفاوت می‌سازد. بازبینی فقط نام سرویس کافی نیست. باید معلوم شود چه بخشی از تصویر ارسال می‌شود، چه هویتی درخواست می‌فرستد و در صورت خطا آیا فایل در صف یا گزارش باقی می‌ماند. تهدیدهای قبلی نیز ممکن است به دلیل این مسیر جدید دوباره باز شوند.
برای جلوگیری از اختلاف میان فایل مدل و واقعیت، در بازبینی درخواست تغییر یک سؤال مشخص مطرح کنید. آیا این تغییر بازیگر، داده، مرز اعتماد یا اختیار مؤلفه‌ای را عوض می‌کند؟ پاسخ مثبت باید به نمای مرتبط و تصمیم تیم اشاره کند. لازم نیست هر اصلاح ظاهری برنامه جلسه کامل تهدید داشته باشد. تغییر در روش ورود، محل ذخیره یا دسترسی شخص ثالث دلیل قوی‌تری برای بازبینی است. ثبت تاریخ تصمیم و مسئول آزمون باعث می‌شود مدل پس از جابه‌جایی اعضای تیم نیز قابل استفاده بماند.
خروجی جلسه و سنجش نتیجه
در پایان کارگاه باید بتوان از یک مسیر داده شروع کرد و تهدید مرتبط، اقدام تعیین‌شده، مالک و شاهد آزمون را پیدا کرد. تعداد شکل‌ها یا تهدیدهای ثبت‌شده معیار مناسبی برای موفقیت نیست. مدلی کوچک که یک نقص اختیار را پیش از انتشار آشکار کند ارزش عملی بیشتری از فهرستی طولانی از عنوان‌های مبهم دارد. برای نمونه رسید، پرونده زمانی قابل بستن است که درخواست متقاطع رد شود، پیوند منقضی رفتار مورد انتظار داشته باشد و مسیر واقعی کارشناس پشتیبانی با فرض‌های مدل سازگار بماند.
یک نفر که در جلسه نبوده باید بتواند نمودار را بخواند و بگوید مشتری چگونه به رسید می‌رسد، کجا هویت بررسی می‌شود و برای کدام فرض هنوز مدرک وجود ندارد. اگر پاسخ دشوار است، نام جریان‌ها، جهت پیکان و دلیل مرزها را اصلاح کنید. چنین بازخوانی مستقلی ضعف‌های ارتباطی مدل را پیش از آنکه در طراحی به اختلاف تبدیل شوند آشکار می‌کند. Threat Dragon محل مشترکی برای همین بحث و ثبت نتیجه فراهم می‌کند و ارزش آن زمانی دیده می‌شود که تصمیم ثبت‌شده به رفتار آزموده در محصول برسد.
