Credential Compromise

1. یک signal مشکوک، مرز compromise را ثابت نمی‌کند

ورود از دستگاه جدید، تغییر recovery channel، استفاده از password لو‌رفته یا یک session غیرمنتظره همگی signal هستند؛ اما از روی یک signal نمی‌توان گفت دقیقاً authenticator، session، delegated token یا recovery path compromise شده است. این درس تصمیم را به evidence قابل‌بررسی محدود می‌کند و هر بخش بدون مدرک را UNKNOWN نگه می‌دارد.

2. چهار state را جدا نگه دارید

برای این incident چهار محور مستقل داریم: authenticator state، session state، recovery state و delegated-access state. تعویض password فقط authenticator مربوط را تغییر می‌دهد؛ ممکن است session یا token قبلی همچنان معتبر باشد. برعکس، stolen session می‌تواند رخ دهد در حالی که authenticator اصلی سالم مانده است.

3. NIST درباره authenticator compromise چه می‌گوید

NIST SP 800-63B-4 می‌گوید authenticator compromise‌شده باید پس از تشخیص، promptly suspend، invalidate یا destroy شود و invalidation را حذف binding بین authenticator و subscriber account تعریف می‌کند. [NIST-63B4] این authority برای authenticator است؛ از آن نمی‌توان خودکار نتیجه گرفت که تمام application sessionها یا delegated tokenها خاتمه یافته‌اند.

4. MFA مهم است، اما اثبات closure نیست

OWASP MFA را دفاع بسیار قوی در برابر بخش عمده حملات password-based مثل credential stuffing می‌داند و در کنار آن defense-in-depth و monitoring را توصیه می‌کند. [OWASP-CREDENTIAL] بنابراین MFA یک control مهم است، نه اثبات اینکه هیچ session سرقت‌شده، recovery abuse یا delegated access باقی نمانده است.

5. Timeline بسازید، narrative نه

هر record باید زمان signal، تغییر authenticator، ایجاد یا ادامه session، تغییر recovery channel و token activity را جدا ثبت کند. Timeline کمک می‌کند بین «پس از reset مشاهده شد» و «به علت reset بسته شد» فرق بگذاریم. اگر ترتیب زمانی معلوم نیست، causality را حدس نزنید.

6. Blast radius را مسیر به مسیر ببندید

Blast radius یعنی کدام access pathها واقعاً امکان دسترسی دارند: authenticator، active session، delegated token یا recovery path. scope باید بر اساس state مشاهده‌شده تعیین شود، نه بر اساس ترس از بدترین سناریو. اگر evidence ناقص است، blast radius را bounded و همراه با UNKNOWN ثبت کنید.

7. Suspicious login مساوی takeover نیست

یک login از IP یا device جدید ممکن است legitimate باشد. برای classification باید حداقل یک corroborating signal، state inconsistency یا access-path evidence وجود داشته باشد. case کنترل منفی این درس recovery change مشکوکی است که بعداً legitimate ثابت می‌شود؛ در آن case incident نباید بی‌دلیل به account takeover تبدیل شود.

8. Containment را از recovery جدا کنید

Containment می‌تواند suspend کردن authenticator مشکوک، terminate کردن session، revoke کردن token یا freeze کردن recovery path باشد. Recovery یعنی مسیر مشروع کاربر بازسازی و مسیر compromise‌شده مستقل verify شود. اقدام containment باید reversible و متناسب با evidence باشد، نه کورکورانه و فراگیر.

9. Password rotation فقط یک path را می‌بندد

اگر password compromise شده باشد، rotation بخشی از recovery است. اما fixture این درس صریحاً حالتی دارد که rotation موفق است و old session هنوز فعال است. بنابراین closure باید session registry، token state و recovery state را جدا بسنجد.

10. Session compromise با credential compromise یکی نیست

در transfer fixture authenticator سالم است ولی یک session سرقت‌شده suspect/confirmed می‌شود. پاسخ اصلی در این حالت terminate/revoke همان session و بازبینی session scope است، نه الزاماً rotation همه credentials. این تمایز جلوی over-response و blind spot را هم‌زمان می‌گیرد.

11. Delegated token را فراموش نکنید

API token یا delegated grant می‌تواند بعد از invalidation authenticator فعال بماند، بسته به architecture. record باید token scope و revocation state را جدا ثبت کند. اگر state آن معلوم نیست، نمی‌توان containment را complete اعلام کرد.

12. Recovery channel خودش یک access path است

تغییر email/phone/recovery factor ممکن است signal compromise باشد و گاهی مسیر persistence مهاجم. قبل از restore باید معلوم باشد recovery change authorized بوده یا نه. در صورت evidence ناکافی، تصمیم OPEN_BOUNDARY_UNRESOLVED معتبرتر از داستان‌سازی است.

13. Closure به independent probe نیاز دارد

پس از containment، همان symptom قبلی را صرفاً دوباره نگاه نکنید. برای authenticator، invalidation/binding state؛ برای session، session termination؛ برای token، revocation؛ و برای recovery، authorized recovery state را مستقل verify کنید. closure تنها وقتی بسته می‌شود که pathهای در scope واقعاً invalid شوند یا residual uncertainty صریحاً باقی بماند.

14. Lab: هشت fixture و ۶۴ assertion

Lab کاملاً local و synthetic است. هشت case شامل baseline سالم، authenticator compromise، session باقی‌مانده بعد از password rotation، delegated token باقی‌مانده، recovery compromise، false-positive recovery signal، evidence ناقص و transfer stolen-session است. evaluator مخفی برای هر case هشت خروجی را می‌سنجد؛ در مجموع ۶۴ assertion.

15. Exit checklist و claim boundary

برای خروج باید بتوانید چهار state اصلی را جدا کنید؛ یک alternative را با evidence رد کنید؛ blast radius را bounded بسازید؛ containment و closure را یکی نگیرید؛ UNKNOWN را حفظ کنید؛ transfer case را از نو تحلیل کنید؛ و روشن بگویید که موفقیت fixture فقط reasoning این محیط synthetic را ثابت می‌کند، نه نبود compromise در یک سامانه واقعی.