تفاوت تهدید، آسیب‌پذیری و ریسک در امنیت سایبری چیست؟

ببین، فرض کن مسئول بررسی امنیت یک آموزشگاه شدی و هم‌زمان سه گزارش به دستت رسیده: بعضی دانشجوها کارنامه خودشون رو نمی‌بینن، ورود به پنل مربی‌ها محافظت کافی نداره و عکس یکی از دوره‌ها هم لود نمی‌شه. مدیر می‌گه «همه‌شون خطر امنیتی دارن؛ سریع درستشون کنید!» ولی ما هنوز نمی‌دونیم کدوم واقعاً ضعف امنیتیه، چه اتفاقی ممکنه ازش به وجود بیاد و رسیدگی به کدوم فوریت بیشتری داره. برای همین باید اول فرق تهدید، آسیب‌پذیری و ریسک رو بفهمیم، وگرنه هر خطایی رو با برچسب «بحرانی» گزارش می‌کنیم.

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

تهدید، آسیب‌پذیری و ریسک چیست؟ تفاوت ۳ مفهوم با مثال

برای فهمیدن تهدید، آسیب‌پذیری و ریسک اول سه اصطلاح رو از هم جدا کنیم. تهدید (Threat) یعنی رویداد یا شرایطی که ظرفیت آسیب زدن داره. آسیب‌پذیری (Vulnerability) یعنی ضعفی که می‌تونه در یک سناریو به آسیب کمک کنه. ریسک (Risk) هم برآورد احتمال و پیامد اون سناریوی نامطلوبه. پس وقتی می‌پرسی «تفاوت تهدید و آسیب پذیری و ریسک چیه؟» درواقع دنبال سه جواب متفاوتی: چه اتفاقی ممکنه بیفته، چه ضعفی راه رو باز می‌کنه و اگر اتفاق افتاد، چقدر باید نگران باشیم؟

این جدول، فرق تهدید، آسیب‌پذیری و ریسک رو در یک نگاه نشون می‌ده؛ ولی قرار نیست فکر کنی هر تهدید فقط یک آسیب‌پذیری داره. ممکنه چند ضعف با هم باعث یک اتفاق بشن یا یک قطعی برق بدون هیچ باگ نرم‌افزاری، ارائه خدمات رو مختل کنه. از همین اول حواست باشه: دیدن یک پورت باز یا یک هشدار قرمزرنگ، به‌تنهایی اثبات حمله، آسیب‌پذیری یا ریسک بحرانی نیست.

تهدید در امنیت سایبری چیست؟ معنی Threat با مثال

برای اینکه بفهمی تهدید در امنیت سایبری یعنی چی، فقط مهاجم‌ها رو در نظر نگیر. کسی که سعی می‌کنه وارد حساب دیگری بشه، خرابی برق اتاق سرور، حذف اشتباهی یک فایل و انتشار بدافزار همگی می‌تونن در سناریوهای متفاوت تهدید ایجاد کنن. اصطلاح Threat چیست رو اگر در منابع انگلیسی دیدی، دنبال «رویداد یا شرایط بالقوه آسیب‌زا» باش، نه صرفاً «فرد هکر». تعریف رسمی NIST برای Threat هم همین نگاه گسترده رو پوشش می‌ده.

یه تفاوت ریز این وسط هست: منبع تهدید با اتفاق تهدیدآمیز یکی نیست. فرض کن کارمندی ناخواسته فایل نمره‌ها رو پاک می‌کنه. کارمند می‌تونه عامل انسانی رویداد باشه؛ اتفاقی که نگرانشیم از دست رفتن داده‌ست. حالا اگر کسی بخواد به حساب مربی دسترسی غیرمجاز بگیره، اون فرد منبع تهدیده و دسترسی غیرمجاز، سناریوی مورد بررسی ماست. توی تحلیل تهدید، آسیب‌پذیری و ریسک همین دقت در نام‌گذاری کمک می‌کنه کنترل مناسبی پیشنهاد بدی.

تهدید همیشه عمدی نیست

تصور کن سرور نوبت‌دهی یک کلینیک برق اضطراری مناسبی نداره. بدون اینکه کسی قصد حمله داشته باشه، قطعی برق می‌تونه کار مراجعه‌کننده‌ها رو مختل کنه. در تحلیل تهدید، آسیب‌پذیری و ریسک باید سناریو رو کامل ببینی. از اون طرف، ایمیل فیشینگ با هدف دزدیدن رمز عبور یک تهدید عمدیه. هر دو مهمن، اما روش پیشگیریشون یکسان نیست. پس اگر دانشجویی بپرسه «تهدید یعنی حتماً یک نفر قصد نفوذ داره؟»، جوابش نه‌ست؛ گاهی با خطای انسانی، خرابی تجهیزات یا اتفاق محیطی طرفیم.

آسیب‌پذیری در امنیت سایبری چیست؟ تعریف Vulnerability

حالا برسیم به آسیب پذیری در امنیت سایبری. آسیب‌پذیری می‌تونه یک اشتباه در کد، تنظیمات ناامن سرور، مجوزدهی ناقص یا ضعف فرایند کاری باشه. مثلاً اگر دانشجو بتونه بدون اجازه کارنامه شخص دیگه رو ببینه، احتمالاً کنترل دسترسی درست پیاده نشده. در مقابل، فایل پشتیبانِ بدون محافظت هم ممکنه راه افشای داده رو باز کنه. برای سؤال «Vulnerability چیست؟» به تعریف NIST درباره Vulnerability رجوع کن؛ ضعف فقط به باگ نرم‌افزاری محدود نمی‌شه.

اینجا یک سوءتفاهم رایج داریم: پیدا شدن یک ضعف یعنی حتماً ازش سوءاستفاده شده؟ نه. ممکنه ضعف واقعاً وجود داشته باشه ولی هیچ شواهدی از نفوذ نداشته باشیم. ممکنه هم ابزار خودکار هشدار داده باشه و بعد از بررسی بفهمیم خطای تشخیص بوده. وقتی تهدید، آسیب‌پذیری و ریسک رو تحلیل می‌کنی، «هشدار ابزار»، «ضعف تأییدشده»، «امکان سوءاستفاده» و «حادثه رخ‌داده» رو به‌جای هم ننویس؛ هرکدوم شواهد خودش رو لازم داره.

آیا هر باگ، آسیب‌پذیری امنیتیه؟

نه، هر باگی آسیب‌پذیری نیست. مثلاً اگه گوشه یک دکمه روی موبایل بد نمایش داده بشه، احتمالاً یک ایراد ظاهری داریم. ولی وقتی کاربر معمولی بدون مجوز به فایل خصوصی دیگری دسترسی پیدا کنه، بحث محرمانگی داده مطرح می‌شه. برای تفاوت تهدید و آسیب پذیری هم همین منطق رو به خاطر بسپار: تهدید درباره اتفاق بالقوه آسیب‌زاست و آسیب‌پذیری درباره ضعف قابل استفاده در اون سناریو. پس توی بحث تهدید، آسیب‌پذیری و ریسک صرف وجود یک ایراد UI کافی نیست که بگیم امنیت سیستم شکسته شده.

آیا آسیب‌پذیری فقط در کد نرم‌افزاره؟

حتماً نه. ممکنه کد احراز هویت درست نوشته شده باشه، اما رمز یک حساب مهم در یک فایل عمومی نگهداری بشه. یا تیم نسخه پشتیبان داشته باشه ولی هیچ‌وقت بازیابیش رو آزمایش نکرده باشه. حتی نبود فرایند تأیید درخواست تغییر اطلاعات هم می‌تونه خطر درست کنه. برای همین ارزیاب امنیت باید هم کد رو ببینه، هم پیکربندی و هم رفتار آدم‌ها رو؛ فقط دنبال یک خط اشتباه توی برنامه نگرده.

ریسک در امنیت سایبری چیست؟ تعریف Risk و پیامد

سؤال «Risk چیست؟» رو با یک مثال جواب می‌دم: فرض کن ضعف دسترسی به کارنامه‌ها وجود داره؛ حالا چقدر ممکنه کسی ازش استفاده کنه و اگر استفاده کرد چه آسیبی به دانشجو و آموزشگاه می‌رسه؟ همین دو محور، نقطه شروع تحلیل ریسک در امنیت سایبری هستن. مدل آموزشی «احتمال وقوع × پیامد» کمک می‌کنه موضوع رو مرتب ببینی. این مدل با رویکرد NIST درباره Risk و روش ارزیابی ریسک OWASP سازگاره، اما یک فرمول دقیق جهانی برای همه سازمان‌ها نیست.

Risk (conceptually) = Likelihood × Impact

Likelihood = How plausible is the event?
Impact     = How harmful would it be?

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

اول دارایی رو بشناس؛ بدون دارایی، ریسک معنای روشنی نداره

ببین، قبل از بحث احتمال و آسیب باید بدونیم اصلاً داریم از چی محافظت می‌کنیم. به این چیز ارزشمند می‌گیم دارایی (Asset)؛ از سرور و دیتابیس گرفته تا کارنامه دانشجو، اعتبار آموزشگاه و دسترس‌پذیری سامانه آزمون. اگر تصویر یک بنر عمومی لود نشه، اثرش با افشای نمره‌های خصوصی یکسان نیست. تحلیل تهدید، آسیب‌پذیری و ریسک بدون شناخت دارایی و صاحب اون، معمولاً به اولویت‌بندی اشتباه می‌رسه.

برای همین دوست ندارم دانشجو فقط خروجی Scanner رو گزارش امنیتی بدونه. ممکنه یک ضعف فنی در محیط کاملاً جداشده آزمایشی، اثر کمتری از یک ضعف ظاهراً ساده در سامانه اصلی ثبت نمره داشته باشه؛ البته این هم فرضیه‌ست تا وقتی ارتباط محیط‌ها و نوع داده‌ها رو بررسی نکردیم. از اسم محیط یا رنگ هشدار نمی‌شه نتیجه نهایی گرفت. باید شرایط واقعی استفاده از سیستم رو شناخت.

تفاوت تهدید، آسیب‌پذیری و ریسک در سناریوی آموزشگاه سپهر

حالا برگردیم به «آموزشگاه سپهر»؛ یک آموزشگاه کاملاً خیالی که سایت آزمون آنلاین داره. دانشجوها کارنامه می‌بینن، مربی‌ها نمره ثبت می‌کنن و مدیر گزارش می‌گیره. سه مشکل به تیم فنی گزارش شده و ما می‌خوایم بدون دست زدن به هیچ سایت واقعی، براشون تحلیل اولیه بنویسیم. این تمرین کمک می‌کنه رابطه تهدید، آسیب‌پذیری و ریسک و تفاوت Threat و Vulnerability و Risk رو به‌جای حفظ کردن سه تعریف انگلیسی، توی یک مسئله قابل لمس ببینی.

گزارش الف : چه چیزی تهدیده و چه چیزی آسیب‌پذیری؟

در گزارش اول، تیم تست با دو حساب ساختگی فهمیده بررسی مجوز مشاهده کارنامه در بعضی درخواست‌ها درست عمل نمی‌کنه. این می‌تونه یک آسیب‌پذیری کنترل دسترسی باشه. سناریوی تهدید، تلاش یک کاربر برای دیدن کارنامه دیگریه. ریسک هم به احتمال رخ دادن و پیامد احتمالی افشای اطلاعات بستگی داره. دقت کن: ما هنوز درباره داده واقعی هیچ تستی نکردیم؛ بنابراین نباید بنویسیم «اطلاعات همه دانشجوها لو رفته».

گزارش ب : آیا نداشتن یک کنترل همیشه به معنی نفوذ قطعی است؟

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

گزارش ج : آیا هر مشکل فوری، مشکل امنیتی است؟

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

چرا یک آسیب‌پذیری ثابت در دو سازمان ریسک یکسانی ندارد؟

همون ضعف کنترل دسترسی رو یک بار روی لپ‌تاپ آزمایشی بدون اطلاعات واقعی تصور کن و یک بار روی سایت اصلی با هزاران کارنامه. شاید خطای کد دقیقاً یکی باشه، اما میزان در معرض دسترس بودن، ارزش داده و پیامد سوءاستفاده فرق می‌کنه. توی چنین مثالی رابطه تهدید، آسیب‌پذیری و ریسک روشن می‌شه و تفاوت ریسک و آسیب پذیری روشن می‌شه: شدت فنی یک ضعف، تمام تصویر ریسک سازمان نیست. برای همین امتیاز آسیب‌پذیری رو نباید بدون تحلیل محیط، مستقیماً به اولویت کسب‌وکار تبدیل کنیم.

البته اینکه یک سرور برچسب «تست» داره هم دلیل نمی‌شه ریسکش صفر باشه. شاید به دیتابیس اصلی وصل باشه یا کلیدهای واقعی روی اون باقی مونده باشن. پس چه درباره محیط تست حرف بزنیم چه Production، باید وابستگی‌ها و دسترسی‌ها رو بررسی کنیم. نتیجه درست از شواهد میاد، نه اسم محیط.

احتمال وقوع و شدت پیامد رو جداگانه بررسی کن

یکی از جاهایی که تحلیل تهدید، آسیب‌پذیری و ریسک از حالت حفظی درمیاد، جدا کردن «احتمال» از «پیامد»ه. افشای نمره‌ها می‌تونه پیامد جدی داشته باشه، اما برای برآورد ریسک باید امکان وقوع سناریو رو هم بررسی کنیم. گاهی حادثه‌ای با پیامد کمتر، به‌خاطر تکرار زیاد هزینه مهمی ایجاد می‌کنه. برای شروع می‌تونی برچسب کم، متوسط یا زیاد بذاری؛ به شرط اینکه برای هر برچسب دلیل روشن داشته باشی.

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

محاسبه آموزشی ارزیابی ریسک امنیت سایبری با پایتون

حالا با پایتون یه آزمایش کاملاً آفلاین انجام بدیم. سه سناریوی فرضی داریم و برای هرکدوم دو عدد ۱ تا ۵ انتخاب کردیم: یکی برای احتمال و یکی برای پیامد. برنامه فقط این عددها رو ضرب و مرتب می‌کنه؛ هیچ درخواست شبکه‌ای نمی‌فرسته و هیچ آسیب‌پذیری‌ای رو اسکن نمی‌کنه. عددهای این تمرین ساختگی‌ان و نباید خروجی رو معادل CVSS یا روش رسمی Risk Assessment فرض کنی.

risks = [
    {"name": "Student records exposure", "likelihood": 4, "impact": 5},
    {"name": "Admin account misuse", "likelihood": 3, "impact": 4},
    {"name": "Public banner outage", "likelihood": 2, "impact": 1},
]

for item in risks:
    item["score"] = item["likelihood"] * item["impact"]

for item in sorted(risks, key=lambda risk: risk["score"], reverse=True):
    print(item["name"], item["score"])

اگر برنامه رو دقیقاً مثل نمونه اجرا کنی، خروجی مرتب‌شده اینه:

Student records exposure 20
Admin account misuse 12
Public banner outage 2

دیدی؟ برنامه خیلی مرتب عددهای ۲۰، ۱۲ و ۲ رو تحویل داد، ولی از خودش نمی‌دونه احتمال واقعی افشای کارنامه چقدره. برای تحلیل تهدید، آسیب‌پذیری و ریسک ما ورودی‌ها رو انتخاب کردیم و فقط ترتیبشون محاسبه شده. برای تمرین، مقدار احتمال یکی از موارد رو تغییر بده و دوباره اجرا کن. اگر نتیجه جابه‌جا شد، یعنی خروجی به فرض‌های ما وابسته‌ست؛ نه اینکه سیستم موردنظر ناگهان امن یا ناامن شده باشه.

ارزیابی ریسک یا Risk Assessment چیست و چه فرقی با ارزیابی آسیب‌پذیری داره؟

گاهی سؤال می‌پرسن «Risk Assessment چیست و آیا همون پیدا کردن Vulnerabilityهاست؟» نه. Vulnerability Assessment بیشتر روی شناسایی و بررسی ضعف‌ها تمرکز می‌کنه، ولی ارزیابی ریسک امنیت سایبری می‌پرسه چه سناریوی نامطلوبی ممکنه رخ بده، کدوم دارایی درگیره و با توجه به احتمال و پیامد چه تصمیمی باید گرفت. در بررسی تهدید، آسیب‌پذیری و ریسک ارزیابی آسیب‌پذیری می‌تونه به ارزیابی ریسک اطلاعات بده، اما به‌تنهایی جای اون رو نمی‌گیره.

مثلاً ارزیاب فنی می‌تونه ثابت کنه حساب آزمایشی A در شرایط مشخص به کارنامه آزمایشی B دسترسی داره. اما برای اینکه بگه اثر تجاری این مشکل چقدره، احتمالاً باید با مسئول داده‌ها هم صحبت کنه: چه اطلاعاتی حساسن؟ چند نفر ممکنه درگیر بشن؟ چه کنترل جبرانی‌ای داریم؟ وقتی جواب روشن نیست، بهتره عدم قطعیت رو در گزارش بنویسیم تا اینکه عددی بسازیم که فقط دقیق به نظر برسه.

فرق CVSS و ریسک واقعی کسب‌وکار چیه؟

ممکنه توی گزارش‌ها امتیاز CVSS ببینی. این چارچوب برای توصیف ویژگی‌ها و شدت آسیب‌پذیری به درد می‌خوره، اما امتیاز پایه CVSS به‌تنهایی برآورد ریسک کسب‌وکار نیست. وقتی رابطه تهدید، آسیب‌پذیری و ریسک رو درک کنی، متوجه می‌شی در نسخه ۴ هم گروه‌های معیار برای در نظر گرفتن شرایط تهدید و محیط وجود دارن؛ بااین‌حال برای تصمیم سازمانی باید زمینه واقعی رو بررسی کرد. اگر خواستی جزئیات فنی رو بخونی، مستندات رسمی FIRST درباره CVSS v4.0 مرجع مناسبیه.

پس وقتی یک ابزار عدد ۹ یا برچسب Critical نشون می‌ده، اول بپرس این عدد با چه معیارهایی محاسبه شده. آیا فقط شدت فنی رو نشان می‌ده یا عوامل محیطی هم وارد شده؟ چه چیزی هنوز بررسی نشده؟ این نگاه کمک می‌کنه بین هشدار ابزار، شواهد فنی و تصمیم مدیریتی مرز بذاری. برای تفاوت ریسک و آسیب پذیری همین سؤال‌ها خیلی کاربردی‌تر از حفظ کردن رنگ‌ها هستن.

کنترل امنیتی چطور ریسک رو کاهش میده؟

خب حالا چطور ریسک رو کم کنیم؟ با کنترل امنیتی (Security Control)؛ مثل بررسی مجوز سمت سرور، محافظت مناسب از حساب مربی، ثبت رویدادهای ورود یا داشتن پشتیبان قابل بازیابی. هر کنترل باید یک بخش مشخص از سناریوی تهدید، آسیب‌پذیری و ریسک رو هدف بگیره. مثلاً لاگ‌گیری به کشف اتفاق کمک می‌کنه، اما به‌تنهایی ضعف کنترل دسترسی رو برطرف نمی‌کنه. نصب یک ابزار جدید هم تضمین امنیت مطلق نیست.

ریسک اولیه و ریسک باقی‌مانده یعنی چی؟

وقتی گزارش تهدید، آسیب‌پذیری و ریسک رو می‌خونی، اصطلاح‌های Inherent Risk و Residual Risk رو زیاد می‌بینی. اولی معمولاً به ریسک پیش از در نظر گرفتن کنترل‌های مورد ارزیابی اشاره می‌کنه و دومی به ریسکی که بعد از اجرای اون کنترل‌ها باقی می‌مونه. فرض کن کنترل مجوز کارنامه رو درست کردی؛ احتمال سوءاستفاده از همون مسیر می‌تونه کمتر بشه، اما اشتباه پیکربندی یا دسترسی بیش‌ازحد از مسیرهای دیگه همچنان ممکنه وجود داشته باشه.

برای همین بعد از هر اصلاح، سؤال درست این نیست که «دیگه امن شدیم؟»؛ باید بپرسی ریسک باقی‌مانده چیه و آیا کسی که اختیار تصمیم داره اون رو پذیرفته؟ این موضوع توی ارزیابی ریسک امنیت سایبری خیلی مهمه. گاهی رفع یک آسیب‌پذیری فوریه و گاهی هم یک کنترل موقت تا زمان اصلاح اصلی لازمه. هیچ‌کدوم بدون شناخت شرایط سیستم قابل نسخه‌پیچی نیست.

وقتی ریسک بالا بود، همیشه باید سیستم را خاموش کنیم؟

نه، همیشه خاموش کردن سرویس جواب درست نیست. ممکنه با محدود کردن دسترسی، اصلاح کد، تغییر فرایند یا یک کنترل جبرانی، ریسک رو تا زمان رفع کامل پایین آورد. بعضی ریسک‌ها هم با تصمیم مسئول مشخص و در چارچوب قوانین پذیرفته می‌شن؛ البته «پذیرش آگاهانه» با نادیده گرفتن مشکل فرق داره. هدف مدیریت ریسک، تصمیم متناسب با پیامد و هزینه‌ست، نه واکنش عجولانه به هر هشدار.

چه فرقی بین Threat Modeling و Risk Assessment هست؟

توی Threat Modeling معمولاً از خود طراحی سیستم شروع می‌کنیم: داده از کجا وارد می‌شه، چه کسی به چی دسترسی داره و چه اتفاقی ممکنه اشتباه پیش بره؟ اما Risk Assessment روی سنجش و اولویت‌بندی پیامدهای نامطلوب تمرکز بیشتری داره. برای شناخت بهتر تهدید، آسیب‌پذیری و ریسک این دو روش می‌تونن به هم کمک کنن؛ یکی سناریوها رو روشن می‌کنه و دیگری به انتخاب اقدام مناسب کمک می‌کنه. برای آشنایی بیشتر، راهنمای Threat Modeling در OWASP رو ببین.

در آموزشگاه سپهر، قبل از انتشار سامانه می‌تونیم بپرسیم «آیا مربی حق دیدن نمره همه کلاس‌ها رو داره؟» یا «اگر سرویس اعلام نتیجه از کار افتاد، چه کاری از دست دانشجوها برنمیاد؟». جواب این سؤال‌ها سناریوهای مفیدی برای مدل‌سازی تهدیده. بعد وقتی دارایی‌ها، کنترل‌ها و شرایط واقعی رو شناختیم، می‌رسیم به تحلیل تهدید، آسیب‌پذیری و ریسک و تعیین اولویت.

۶ اشتباه رایج در تحلیل تهدید، آسیب‌پذیری و ریسک

اشتباه اول : تهدید را مساوی هکر بدانیم

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

اشتباه دوم : هر هشدار ابزار را آسیب‌پذیری تأییدشده بدانیم

یه Scanner ممکنه بگه «احتمال آسیب‌پذیری هست»، ولی هنوز معلوم نیست هشدارش درسته یا نه. بعد از بررسی هم اگر ضعف تأیید شد، از همون نتیجه نمی‌شه گفت قبلاً حمله‌ای رخ داده. توی گزارش، بین نشانه، شواهد و نتیجه نهایی فاصله بذار.

اشتباه سوم : شدت فنی را با ریسک سازمانی یکی بگیریم

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

اشتباه چهارم : با یک فرمول ساده وانمود کنیم همه‌چیز دقیق شده

مدل احتمال ضربدر پیامد برای شروع خوبه؛ اما وقتی دو عدد از روی حدس انتخاب شده باشن، حاصل ضربشون هم به همون فرض‌ها وابسته‌ست. توی گزارش واقعی، مقیاس، منبع اطلاعات و میزان عدم قطعیت رو واضح بنویس.

اشتباه پنجم : بعد از نصب یک ابزار امنیتی، ریسک را صفر حساب کنیم

نصب فایروال یا فعال کردن MFA به‌تنهایی به معنی «ریسک صفر» نیست. شاید یک کنترل اشتباه تنظیم شده باشه یا مسیر دیگری هنوز باز مونده باشه. بعد از هر تغییر، هم اثر کنترل رو بررسی کن و هم ریسک باقی‌مانده رو.

اشتباه ششم : بدون شناخت مالک داده‌ها اولویت تعیین کنیم

ممکنه فایلی از نظر توسعه‌دهنده بی‌اهمیت به نظر بیاد، ولی از دید صاحب داده حساس یا مشمول تعهد قانونی باشه. قبل از اولویت‌بندی درباره ارزش دارایی از مسئولش سؤال بپرس؛ تیم فنی به‌تنهایی جواب همه پیامدهای تجاری رو نمی‌دونه.

۴ تمرین برای تشخیص تفاوت تهدید و آسیب‌پذیری

تمرین اول : آیا یک پورت باز یعنی ریسک بحرانی؟

فرض کن در آزمایشگاه مجاز، ابزار نشون داده یک پورت روی سرور بازه. آیا همین یعنی ریسک بحرانی؟ جواب: نه. باید سرویس، نسخه، تنظیمات، دسترسی شبکه و شواهد ضعف رو بررسی کنی. پورت باز ممکنه برای کار عادی سامانه لازم باشه.

تمرین دوم : آیا نبود یک مهاجم شناخته‌شده یعنی تهدیدی نداریم؟

یک شرکت می‌گه «تا حالا کسی به ما حمله نکرده؛ پس خطری نداریم.» این نتیجه درسته؟ نه. نداشتن گزارش حادثه با نداشتن تهدید فرق داره. تازه بعضی رویدادها مثل خطای انسانی یا خرابی تجهیزات اصلاً به مهاجم وابسته نیستن.

تمرین سوم : دو مشکل با نمره مشابه

دو سناریوی فرضی امتیاز برابر گرفتن؛ یکی احتمال بالاتر با پیامد کمتر داره و یکی برعکس. کدوم رو اول اصلاح می‌کنی؟ جواب: با همین دو عدد نمی‌شه تصمیم قطعی گرفت. نظر مالک داده، پیامد حقوقی، زمان اصلاح و کنترل‌های فعلی ممکنه اولویت رو تغییر بدن.

تمرین چهارم : آیا برطرف شدن آسیب‌پذیری، ریسک را حذف می‌کند؟

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

این درس چه ارتباطی با تست نفوذ و گزارش‌نویسی دارد؟

اگر قصد داری وارد مسیر آموزش تست نفوذ بشی، تفاوت تهدید، آسیب‌پذیری و ریسک از پایه‌های گزارش‌نویسیه. متخصص تست نفوذ باید مشخص کنه چه ضعفی رو دیده، چه چیزی رو واقعاً آزمایش کرده و اثر احتمالی روی سیستم چیه. جمله «این سایت خیلی خطرناکه» بدون شواهد کمکی به توسعه‌دهنده نمی‌کنه؛ گزارش خوب باید به تصمیم و اصلاح منجر بشه.

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

سؤالات متداول درباره تهدید، آسیب‌پذیری و ریسک

منابع معتبر برای بررسی تعریف‌های فنی

برای اینکه تعریف‌ها رو با حدس جلو نبری، سراغ واژه‌نامه رسمی NIST درباره Threat، Vulnerability و Risk برو. برای روش ارزیابی هم OWASP Risk Rating Methodology مفیده. مثال آموزشگاه سپهر، نمره‌ها و تصمیم‌های این درس ساختگی‌ان؛ منابع رسمی رو برای بررسی دقت مفهوم‌ها گذاشتم.

جمع‌بندی : به‌جای ترسیدن از واژه‌ها، سناریو رو تحلیل کن

اگر فقط یک چیز از این درس یادت بمونه، همین باشه: قبل از اینکه به یک هشدار بگی «ریسک بحرانی»، دارایی رو مشخص کن، سناریوی تهدید رو توضیح بده، ضعف احتمالی رو با شواهد بررسی کن و بعد درباره احتمال و پیامد حرف بزن. شناخت تهدید، آسیب‌پذیری و ریسک یعنی از یک پیام خطا به یک تصمیم قابل دفاع برسی؛ نه اینکه با چند عدد، گزارش رو ترسناک‌تر کنی. با هشدار بعدی از خودت بپرس: چی در خطره، چه شواهدی داریم و چه اقدامی کمک می‌کنه؟