مدل‌سازی تهدید: یک جلسه، یک صفحه، پیش از کدنویسی

تیم آرادتیم مهندسی

«مدل‌سازی تهدید» اسم ترسناکی دارد و همین اسم باعث شده در بیشتر پروژه‌های متوسط اصلاً انجام نشود. تصور غالب این است که کار تیم امنیت است، هفته‌ها طول می‌کشد و به یک سند صد صفحه‌ای ختم می‌شود.

در عمل چیز دیگری است: یک جلسهٔ نود دقیقه‌ای با تیم فنی، روی یک وایت‌برد، که خروجی‌اش یک صفحه است. و آن یک صفحه معمولاً دو یا سه تصمیم معماری را عوض می‌کند — که تنها لحظه‌ای است که عوض کردنشان ارزان است.

چه وقت ارزش دارد

نه برای هر پروژه. معیار ما ساده است: اگر سامانه یکی از این‌ها را دارد، ارزش دارد.

  • پول جابه‌جا می‌کند یا موجودی مالی نگه می‌دارد
  • دادهٔ هویتی یا درمانی نگه می‌دارد
  • چند سازمان مستقل روی یک نصب کار می‌کنند (چندمستأجری)
  • بخشی از آن روی اینترنت عمومی باز است و بخشی نیست

سامانهٔ داخلی گزارش‌گیری که فقط کارمندان به آن دسترسی دارند و دادهٔ حساس ندارد، لازم ندارد. صادق بودن دربارهٔ این تفکیک، چیزی است که باعث می‌شود جلسه در پروژه‌های بعدی هم برگزار شود.

چهار سؤال

روش‌های رسمی زیادی وجود دارد. آنچه در عمل برای ما جواب داده، چهار سؤال است به همین ترتیب.

۱. چه چیزی می‌سازیم؟

یک نمودار، نه بیشتر از یک صفحه. اجزا، و پیکان‌هایی که نشان می‌دهند داده از کجا به کجا می‌رود. مرورگر، اپلیکیشن موبایل، سرور، پایگاه داده، درگاه پرداخت، سرویس پیامک، سامانهٔ مالیاتی.

بعد مرزهای اعتماد را روی همان نمودار خط بکشید. هر جا داده از یک ناحیه با سطح اعتماد متفاوت وارد می‌شود، یک خط. آن خط‌ها جایی هستند که بقیهٔ جلسه دربارهٔ آن‌هاست.

نکته‌ای که مکرراً از قلم می‌افتد: پاسخ سرویس بیرونی هم عبور از مرز است. تیم‌ها ورودی کاربر را اعتبارسنجی می‌کنند و پاسخ درگاه پرداخت را نه.

۲. چه چیزی می‌تواند غلط پیش برود؟

برای هر پیکان و هر مخزن داده، شش دسته را مرور کنید. ترتیبشان مهم نیست، کامل بودنشان مهم است:

جعل هویت — می‌شود جای کس دیگری بود؟ نشست دزدیده می‌شود؟ توکن منقضی می‌شود؟

دستکاری — می‌شود داده را در مسیر عوض کرد؟ کلاسیک‌ترین نمونه: قیمت که در سمت مرورگر محاسبه و به سرور فرستاده می‌شود.

انکار — اگر کاربری بگوید «من این سفارش را ثبت نکردم»، چه چیزی خلافش را نشان می‌دهد؟ اینجاست که ردگیری تغییرات از یک قابلیت گزارش‌گیری به یک الزام تبدیل می‌شود.

افشای اطلاعات — چه کسی چه چیزی را می‌بیند که نباید؟ پیام خطایی که ساختار پایگاه داده را لو می‌دهد. آدرس فایلی که قابل حدس زدن است. لاگی که شمارهٔ کارت دارد.

اختلال سرویس — کدام نقطه با یک درخواست سنگین از پا درمی‌آید؟ گزارشی که بدون محدودیت صفحه‌بندی کل جدول را می‌خواند، نمونهٔ همیشگی است.

ارتقای دسترسی — می‌شود از نقش پایین به بالا رفت؟ شناسهٔ رکورد در آدرس عوض شود، چه اتفاقی می‌افتد؟

این آخری، در سامانه‌های سازمانی ایرانی، بیشترین یافتهٔ واقعی را تولید می‌کند — چون مدل دسترسی معمولاً بر اساس منو طراحی شده، نه بر اساس داده.

۳. چه کار می‌کنیم؟

برای هر تهدید، یکی از چهار جواب. و جواب سوم و چهارم هم جواب معتبرند:

  • کاهش — تغییری در طراحی یا کد که ریسک را کم می‌کند.
  • انتقال — سپردن به کسی که کارش همین است. نگه نداشتن شمارهٔ کارت و سپردنش به درگاه پرداخت، نمونهٔ کلاسیک.
  • پذیرش — ریسک هست، هزینهٔ رفعش بیش از خسارتش است، و این تصمیم با تاریخ و اسم ثبت می‌شود.
  • حذف — قابلیت را نمی‌سازیم. کم پیش می‌آید و وقتی پیش می‌آید ارزان‌ترین جواب است.

پذیرش ثبت‌نشده، همان چیزی است که یک سال بعد در ممیزی به «چرا کسی به این توجه نکرد؟» تبدیل می‌شود. جای ثبتش دفتر یافته‌های امنیتی است.

۴. کارمان را خوب انجام دادیم؟

سؤالی که تقریباً همیشه جا می‌ماند. سه بند:

هر تهدیدی که تصمیم «کاهش» گرفت، یک تست دارد؟ اگر نه، تصمیم روی کاغذ مانده.

مدل تهدید کنار ثبت تصمیم‌ها بایگانی شده تا نفر بعدی پیدایش کند؟

محرک بازنگری چیست؟ «هر شش ماه» محرک نیست. «وقتی نقطهٔ ورودی عمومی جدیدی اضافه شد» یا «وقتی نوع دادهٔ حساس تازه‌ای وارد سامانه شد» محرک است.

سه اشتباهی که جلسه را بی‌فایده می‌کند

دعوت کردن آدم‌های غلط. این جلسه بدون کسی که کد را می‌نویسد بی‌معناست. مدل تهدیدی که تیم امنیت به‌تنهایی نوشته، سندی است که تیم توسعه نمی‌خواندش.

رفتن سراغ حملهٔ جذاب. بحث دربارهٔ حمله‌های پیچیده جذاب است و کم‌بازده. بیشتر رخنه‌های واقعی از چند اشتباه تکراری می‌آیند، نه از حملهٔ خلاقانه — فهرستشان اینجاست.

نساختن هیچ کاری از خروجی. مدل تهدیدی که به آیتم بک‌لاگ تبدیل نشود، فایل است نه تصمیم. قاعدهٔ ما: جلسه تمام نمی‌شود تا هر تصمیم «کاهش» یک آیتم با مسئول داشته باشد.

چقدر طول می‌کشد، واقعاً

برای یک سامانهٔ متوسط: نود دقیقه برای اولین بار، و بیست دقیقه در هر بازنگری.

در برابر گزارش تست نفوذی که دو هفته مانده به راه‌اندازی می‌رسد و یافته‌هایش تصمیم معماری‌اند، این ارزان‌ترین کار امنیتی است که یک تیم می‌تواند انجام دهد. جایگاهش در کل مسیر، در امنیت در همهٔ مراحل تولید آمده.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.