یک مدل تهدید مفید توضیح می‌دهد که از چه چیزی محافظت می‌کنید، چه کسی یا چه چیزی می‌تواند بر آن تأثیر بگذارد، اعتماد کجا تغییر می‌کند و چگونه مهم‌ترین ریسک‌ها را کاهش و آزمایش خواهید کرد. با پروژه واقعی شروع کنید، نه با فهرست عمومی ابزارها.
دامنه‌ای را تعریف کنید که به‌قدر کافی کوچک باشد تا درباره آن استدلال شود
با یک سرویس در حال کار شروع کنید: یک پورتال مشتری، سایت انتشار یا برنامه داخلی. اجزایی را که اداره می‌کنید و سیستم‌های خارجی‌ای که به آن‌ها وابسته‌اید بنویسید. یک مدل تهدید باید فرض‌ها را قابل مشاهده کند، نه اینکه پیشنهاد دهد هر حمله ممکن حل شده است. نسخه اول را به‌قدری کوچک نگه دارید که افرادی که برنامه را مستقر می‌کنند بتوانند آن را بدون مشاور جداگانه‌ای که نمودار را تفسیر کند توضیح دهند.
نتایج و دارایی‌های ارزشمند را فهرست کنید. این‌ها ممکن است شامل داده مشتری، دسترسی مدیریتی، وضعیت پرداخت، محتوای منتشرشده و توانایی بازیابی سرویس باشد. دسترس‌پذیری می‌تواند حتی وقتی اطلاعات عمومی است یک دارایی باشد. تصمیم بگیرید کدام خرابی‌ها ناخوشایند و کدام‌ها برای افراد یا سازمان زیان‌آور خواهند بود. این تمایز به شما کمک می‌کند کنترل‌ها را اولویت‌بندی کنید، نه اینکه با هر هشدار یکسان برخورد کنید.
جاهایی را ترسیم کنید که اعتماد تغییر می‌کند
راهنمای مدل تهدید OWASP از جریان‌های داده و مرزهای اعتماد برای قابل‌فهم کردن یک طراحی استفاده می‌کند. برای یک برنامه کوچک میزبانی‌شده، مرورگر، فرایند وب، پایگاه داده، مدیر، مقصد پشتیبان‌گیری و یکپارچه‌سازی‌های خارجی را ترسیم کنید. اطلاعاتی را که بین آن‌ها جابه‌جا می‌شود علامت‌گذاری کنید. درخواستی که از یک کلاینت غیرقابل اعتماد به یک عملیات سرور ممتاز عبور می‌کند، شایسته اعتبارسنجی و مجوزدهی صریح است.
فرض نکنید که قرار گرفتن در همان ماشین، همه اجزا را به یک اندازه قابل اعتماد می‌کند. یک فرایند بارگذاری عمومی نباید همان مجوزهای مدیریت پایگاه داده را داشته باشد. یک کار پشتیبان‌گیری ممکن است به دسترسی خواندن نیاز داشته باشد، بدون توانایی تغییر سوابق برنامه فعال. جداسازی این نقش‌ها، مهار اثر یک جزء به‌خطرافتاده را آسان‌تر و بازبینی مجوزهای لازم را ساده‌تر می‌کند.
سناریوهای خرابی مشخص را انتخاب کنید
از چند رویداد باورپذیر برای به چالش کشیدن طراحی استفاده کنید. مهاجم رمز عبور مدیر را می‌دزدد؛ کاربری رکورد کاربر دیگری را درخواست می‌کند؛ یک بارگذاری دیسک را پر می‌کند؛ یک استقرار فایل پیکربندی را افشا می‌کند؛ یک نسخه بازیابی قابل بازیابی نیست. شرایط شروع، جزء تحت تأثیر و پیامد را توصیف کنید. یک سناریوی مشخص آسان‌تر از یک دستور کلی برای بهبود امنیت قابل آزمایش است.
اشتباهات و سوءاستفاده از گردش کار مشروع را نیز در کنار نفوذ خارجی بگنجانید. یک تلاش مجدد ممکن است دو عملیات ارزشمند ایجاد کند، یا دو درخواست برای تغییر همان شیء با هم رقابت کنند. راهنمای منطق کسب‌وکار OWASP این فرض‌های فرایندی را برجسته می‌کند. بررسی کنید چه کسی مجاز است یک گردش کار را به حالت بعدی ببرد و آیا تکرار یا تغییر ترتیب یک درخواست نتیجه را به‌طور غیرمنتظره تغییر می‌دهد.
| سناریو | کنترلی که باید بررسی شود | شواهدی که باید جمع‌آوری شود |
|---|---|---|
| اعتبارنامه مدیریتی دزدیده‌شده | دسترسی محدود و عامل دوم در صورت پشتیبانی | ورود غیرمجاز نمی‌تواند کامل شود |
| درخواست شیء کاربر دیگر | مجوزدهی شیء در سمت سرور | یک آزمایش جداگانه نتیجه رد را برمی‌گرداند |
| دیسک با بارگذاری‌ها پر شده است | کنترل‌های اندازه، سهمیه و نگهداری | یک محدودیت پیش از خرابی سرویس اعمال می‌شود |
| درخواست تکراری گردش کار | تکرارپذیری و مرزهای تراکنش | یک درخواست تکراری یک نتیجه ایجاد می‌کند |
بر اساس تأثیر و مسیر باورپذیر اولویت‌بندی کنید
برای هر سناریو، تأثیر بالقوه آن و شرایط لازم برای وقوع آن را ثبت کنید. تظاهر نکنید که یک امتیاز عددی حدسی، احتمال دقیقی است. هنوز می‌توانید یک رمز عبور ضعیف در معرض اینترنت را از یک رویداد محلی بسیار مشروط تشخیص دهید. برای ریسک‌های مهم یک مالک و یک گام بعدی عملی تعیین کنید تا مدل کاری ایجاد کند که کسی واقعاً بتواند کامل کند.
چرخه عمر اطلاعات را نیز در کنار به خطر افتادن برنامه در نظر بگیرید. یک خروجی تشخیصی می‌تواند در عملیات عادی، داده غیرضروری را افشا کند. یک فیلد حساب نگهداری‌شده ممکن است مدت‌ها پس از پایان هدفش مواجهه ایجاد کند. بنابراین بازبینی حریم خصوصی می‌تواند اطلاعات را حذف یا نگهداری را کوتاه کند، در حالی که بازبینی امنیتی دسترسی به آنچه باقی می‌ماند را محدود می‌کند. هر دو تغییر وقتی از پروژه محافظت می‌کنند به مدل تعلق دارند.
کنترل‌ها را در یک محیط مجاز آزمایش کنید
یک محیط استیجینگ با مجوزهای نمونه و رکوردهای ساختگی ایجاد کنید. دسترسی ردشده، محدودیت‌های درخواست، تلاش‌های مجدد گردش کار و بازیابی را آزمایش کنید. وقتی داده مصنوعی می‌تواند رفتار را نشان دهد، از داده واقعی مشتری استفاده نکنید. هدف تأیید کنترل است، نه تولید ترافیک حمله چشمگیر. در سیستم‌هایی بمانید که مالک آن‌ها هستید یا صریحاً مجاز به ارزیابی آن‌ها هستید.
ثبت کنید چه چیزی قبول شد، چه چیزی شکست خورد و چه چیزی ناشناخته مانده است. نتیجه اسکنر می‌تواند شواهدی فراهم کند اما جایگزین آزمون قواعد کسب‌وکار برنامه نمی‌شود. به همین ترتیب، یک گزینه حفاظت شبکه، مجوزدهی شیء یا مدیریت فایل محرمانه را تأیید نمی‌کند. نتایج مفید را به سناریو پیوست کنید تا نگهدارندگان آینده بفهمند چرا یک کنترل خاص وجود دارد.
مدل را با تغییرات مرتبط نگه دارید
هنگام افزودن یکپارچه‌سازی، افشای نقطه پایانی جدید، تغییر یک امتیاز دسترسی یا انتقال داده به مقصد دیگر، بخش‌های مرتبط را بازبینی کنید. برای یک ویرایش متنی جزئی نیازی نیست کل معماری را از نو ترسیم کنید. محرک، تغییر یک فرض درباره دسترسی، اطلاعات یا رفتار سیستم است. مدل را در کنار مستندات استقرار و بازیابی نگه دارید، نه به‌عنوان خروجی یک کارگاه یک‌باره.
SwissOctet فهرستی از گزینه‌های زیرساختی را فراهم می‌کند، نه یک مدل تهدید کامل برنامه. پیکربندی و گزینه‌هایی را انتخاب کنید که از کنترل‌های شما پشتیبانی می‌کنند، سپس استقراری را که ساخته‌اید تأیید کنید. یک مدل کوچک و نگهداری‌شده با اقدامات آزمون‌شده مفیدتر از مجموعه بزرگی از محصولات امنیتی است که توضیح روشنی درباره ریسک‌هایی که رفع می‌کنند ندارند.
چک‌لیست عملی شما.
- دارایی‌ها و پیامدهای شکست را فهرست کنید.
- جریان‌های داده و مرزهای اعتماد را ترسیم کنید.
- سناریوهای مشخص نفوذ، خطا و گردش کار را انتخاب کنید.
- کنترل‌ها و مسئولان را به ریسک‌های مهم اختصاص دهید.
- با داده مصنوعی در محیط مجاز آزمایش کنید.
- هنگام تغییر یک فرض مرتبط، مدل را بازبینی کنید.
جزئیاتی که اهمیت دارند.
آیا برای شروع به یک چارچوب رسمی نیاز دارم؟+
خیر. یک نمودار کوچک و مجموعه‌ای مستند از سناریوها می‌تواند مفید باشد. یک چارچوب کمک می‌کند ریسک‌ها را به‌طور پیوسته بازبینی کنید.
آیا اسکنر آسیب‌پذیری جایگزین مدل‌سازی تهدید می‌شود؟+
خیر. اسکنرها ممکن است ضعف‌های فنی را بیابند، در حالی که مدل تهدید فرض‌های طراحی، مجوزها و گردش‌های کار کسب‌وکار را نیز بررسی می‌کند.
هر چند وقت یک‌بار باید مدل را به‌روزرسانی کنم؟+
هنگام تغییر جریان‌های داده، یکپارچه‌سازی‌ها، امتیازهای دسترسی یا قابلیت‌های افشاشده، بخش‌های متأثر را به‌روزرسانی کنید و ریسک‌های حل‌نشده را به‌طور منظم بازبینی کنید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- OWASP: برگه تقلب مدل‌سازی تهدید cheatsheetseries.owasp.org
- OWASP: مدل‌سازی تهدید در عمل devguide.owasp.org
- OWASP: امنیت منطق کسب‌وکار cheatsheetseries.owasp.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.