Threat Modeling برای Feature و System Boundary

بازبینی امنیتی زمانی معنی‌دار می‌شود که اول معلوم باشد دقیقاً چه چیزی را بررسی می‌کنیم. فهرست‌کردن چند کنترل امنیتی هنوز Threat Model نیست. در این درس روی یک قابلیت کاملاً ساختگی برای اشتراک‌گذاری سند کار می‌کنید؛ assetها، actorها، entry pointها، data flowها و trust boundaryها را مشخص می‌کنید و بعد هر threat scenario مهم را به کنترل و evidence قابل بررسی وصل می‌کنید.

هدف این درس «اثبات امن‌بودن سیستم» نیست. خروجی باید یک تصمیم محدود و قابل بازبینی باشد که نشان دهد چه چیزی مدل شده، چه چیزی واقعاً در fixture دیده شده، با تغییر boundary چه فرضی از اعتبار افتاده و چه ریسکی هنوز باقی است.

۱. خروجی دقیق درس

در پایان باید Bounded Threat Model Record v1 را برای یک feature ساختگی کامل کنید. هر ردیف مهم این زنجیره را نگه می‌دارد: asset → security objective → actor/entry point → trust boundary → threat scenario → control → evidence check → residual risk → owner decision needed.

فقط happy path کافی نیست. evidence مثبت و منفی هر دو باید حفظ شوند.

۲. سناریوی ساختگی

fixture یک سرویس اشتراک‌گذاری سند را مدل می‌کند. مالک احراز‌شده سند و metadata را ثبت می‌کند. یک collaborator مشخص می‌تواند سند را از طریق application service دریافت کند. metadata و محتوای سند پشت application service قرار دارند. هیچ حساب production، credential واقعی، target خارجی یا تغییر برگشت‌ناپذیر شبکه‌ای وجود ندارد.

سؤال محدود ما این است: وقتی یک boundary را عمداً جابه‌جا می‌کنیم یا یک evidence check را حذف می‌کنیم، آیا مدل امنیتی می‌تواند دقیقاً بگوید کدام فرض و کدام ردیف باید تغییر کند؟

۳. این Record چه چیزی را ثابت می‌کند؟

این Record می‌تواند نشان دهد که در همین fixture ساختگی، یک threat scenario به control و observable مشخص وصل شده است. همچنین می‌تواند نشان دهد که با تغییر trust boundary، بخشی از مدل قبلی دیگر قابل اتکا نیست.

اما production security، کامل‌بودن جهانی threatها، formal risk acceptance یا اجرای صحیح یک کنترل هم‌نام در محیط دیگر را ثابت نمی‌کند.

۴. Asset و Security Objective

از چیزی که باید محافظت شود شروع کنید، نه از اسم کنترل. دو asset اصلی ما document content و document metadata هستند. یک objective محدود می‌تواند این باشد: فقط مالک و collaborator اعلام‌شده اجازه دریافت سند دارند و caller بدون authentication اجازه خواندن metadata را ندارد.

«از authentication استفاده کن» mechanism است. «caller بدون authentication نتواند metadata را بخواند» objective قابل مشاهده است.

۵. Actorها و Entry Pointها

سه actor مهم داریم: owner، collaborator و unauthenticated caller. entry pointهای محدود این درس upload، document retrieval و metadata retrieval هستند.

Admin، billing، CDN، malware scanning، key management و incident response را خودسرانه وارد scope نکنید. ممکن است در یک سیستم واقعی مهم باشند، اما این درس مالک آن outcomeها نیست.

۶. اول Data Flow، بعد Threat Label

قبل از نام‌گذاری threat، مسیر داده را بنویسید:

1. owner/collaborator → application entry point؛
2. application service → metadata store؛
3. application service → storage adapter؛
4. application service → response برای actor مجاز.

وقتی path مشخص نباشد، threat row معمولاً به checklist عمومی تبدیل می‌شود.

۷. Trust Boundary

TB-INTERNET-APP ورودی نامطمئن client را از application service جدا می‌کند. در baseline، storage adapter بخشی از trust zone تحت کنترل application در نظر گرفته شده است. بعداً همین فرض را عمداً تغییر می‌دهیم.

trust boundary صرفاً یک خط روی دیاگرام نیست. اگر component از یک boundary عبور کند، assumptionها و evidence لازم نیز باید بازبینی شوند.

۸. Threat Scenario محدود

سناریوی مفید باید precondition، target asset، path و consequence داشته باشد. نمونه: یک کاربر authenticated سندی را درخواست می‌کند که نه مالک آن است و نه collaborator؛ اگر object-level authorization وجود نداشته باشد، document content ممکن است خارج از boundary مورد انتظار افشا شود.

این claim فقط برای همین مدل محدود است؛ نمی‌گوییم همه سیستم‌ها threat یکسان دارند یا یک taxonomy تمام threatها را پوشش می‌دهد.

۹. Control باید به Threat وصل باشد

برای cross-user read، control پیشگیرانه یک authorization check روی رابطه owner/collaborator در application service است. evidence آن شامل retrieval موفق توسط collaborator مجاز و retrieval ناموفق توسط actor دیگری است.

اگر فقط اسم control وجود داشته باشد ولی evidence check حذف شود، lab آن را CONTROL_UNVERIFIABLE طبقه‌بندی می‌کند.

۱۰. Evidence را از Inference جدا کنید

سه لایه را جدا نگه دارید:

• Fact / design boundary: contract درس چه چیزی را الزام کرده است؛
• Observation: fixture واقعاً چه خروجی داده است؛
• Inference: همان observation در محدوده همین مدل چه نتیجه‌ای را پشتیبانی می‌کند.

یک observation محلی را به ادعای کلی امنیتی تبدیل نکنید.

۱۱. Baseline Evidence

baseline را اجرا کنید. owner و collaborator مجاز به سند دسترسی دارند؛ actor نامرتبط denied می‌شود؛ metadata برای unauthenticated caller denied می‌شود. خروجی واقعی را ثبت کنید، نه فقط policy مورد انتظار را.

این ترکیب positive evidence و denied-path evidence است.

۱۲. Negative Probe امن: خواندن سند بدون مجوز

probe با شناسه unauthorized_document_read فقط از identityهای ساختگی خود fixture استفاده می‌کند. classification مورد انتظار AUTHORIZATION_DENIED است.

نتیجه فقط همین را پشتیبانی می‌کند: در پیکربندی فعلی fixture، این actor نامجاز رد شد. این نتیجه جایگزین اثبات production authorization نیست.

۱۳. Mutation مرزی: Storage خارجی

probe با شناسه external_storage_boundary_mutation، storage adapter را بیرون trust zone تحت کنترل application می‌برد. classification مورد انتظار TRUST_BOUNDARY_CHANGED_REVIEW_REQUIRED است.

این یعنی external storage ذاتاً ناامن نیست. معنی آن این است که مدل قبلی stale شده و باید assumptionهای confidentiality، integrity، service identity و evidence مرتبط دوباره بررسی شوند.

۱۴. Mutation در Entry Point: Metadata بدون Authentication

probe با شناسه unauthenticated_metadata_endpoint شرط authentication را از endpoint ساختگی metadata برمی‌دارد. classification مورد انتظار UNAUTHENTICATED_METADATA_EXPOSURE است.

نکته اصلی روش exploit نیست؛ قانون مدل‌سازی است: وقتی entry point تغییر می‌کند، actor/boundary assumption قبلی دیگر بدون بازبینی معتبر نیست.

۱۵. Control بدون Evidence Check

probe با شناسه control_name_without_evidence_check اسم control را نگه می‌دارد اما verification step را حذف می‌کند. classification مورد انتظار CONTROL_UNVERIFIABLE است.

کنترلی که نتوان گفت چه observableای اجرای واقعی آن را از یک ادعای روی دیاگرام جدا می‌کند، برای این Record قابل اثبات نیست.

۱۶. Evidence ناقص

probe با شناسه evidence_field_removed یکی از fieldهای اجباری Record را حذف می‌کند. classification مورد انتظار EVIDENCE_INCOMPLETE است.

حذف residual risk یا owner decision needed می‌تواند این تصور غلط را بسازد که انتخاب یک کنترل یعنی ریسک کاملاً بسته شده است.

۱۷. Repair بدون پاک‌کردن شکست

Repair یعنی bounded invariant را برگردانید و همان probe تعیین‌کننده را دوباره اجرا کنید. evidence شکست اولیه را پاک نکنید. before/after evidence از یک خروجی سبز نهایی قوی‌تر است.

مثلاً بعد از بیرون‌بردن storage از trust boundary قبلی، ردیف‌های affected را اصلاح کنید و evidence check جدید تعریف کنید؛ وانمود نکنید مدل قبلی همچنان معتبر بوده است.

۱۸. Residual Risk و Owner Decision

بعد از انتخاب control، دقیقاً بنویسید چه چیزی هنوز اثبات نشده است. این fixture، production identity configuration، storage-service policy، network control، key handling، monitoring عملیاتی یا تأیید انسانی را بررسی نمی‌کند.

residual risk معادل formal acceptance نیست. به همین دلیل owner_decision_needed باید صریح بماند.

۱۹. Transfer به Context جدید

در بخش مستقل، یک appointment-sharing feature ساختگی دارید. actorها و حساسیت داده متفاوت‌اند. فقط ردیف‌هایی را بسازید که از asset، entry point، data flow و boundary همان context نتیجه می‌شوند.

کپی‌کردن جدول document-sharing بدون بازسازی reasoning، transfer را fail می‌کند.

۲۰. چهار Shortcut اشتباه

• generic security checklist یک threat model کامل است.
• قبل از ادامه توسعه باید همه threatهای ممکن enumerated شوند.
• threat model ثابت می‌کند سیستم امن است.
• threat model یک سند یک‌باره است و با تغییر boundary عوض نمی‌شود.

هر چهار مورد bounded evidence را با یک نتیجه‌گیری بیش از حد جایگزین می‌کنند.

۲۱. Source و Freshness Boundary

source boundary این درس فقط یک snapshot رسمی از OWASP Threat Modeling Cheat Sheet است که در 2026-09-02 ثبت شده. این منبع فقط process framing فعلی—system modeling، threat identification، mitigation و review/validation—را پشتیبانی می‌کند و به معنی کامل‌بودن یک taxonomy نیست.

review_due برابر 2026-10-02 است. Query 1 در 2026-09-16 اجرا می‌شود؛ بنابراین recheck هنوز due نیست و source scope توسعه داده نمی‌شود.

۲۲. Checklist پایان

submission کامل باید objective محدود، assetها، actorها، entry pointها، data flowها، trust boundaryها، threat scenarioهای مهم، controlها، evidence checkها، حداقل یک mutation امن، residual risk و changed-context decision را داشته باشد. observation و inference جدا می‌مانند و تصمیم نهایی learner از قبل پر نشده است.