وقتی در جلسه‌ای گفته میشود «ما از چارچوب NIST پیروی می‌کنیم»، معمولاً روشن نیست منظور کدام سند است. NIST یک مؤسسه است، نه یک استاندارد؛ و دست‌کم دو سند آن مستقیماً به کار سازمان‌هایی می‌آید که می‌خواهند وضعیت امنیتی‌شان را بسنجند: Cybersecurity Framework برای حاکمیت و SP 800-115 برای فرایند آزمون فنی. این مقاله این دو را از هم تفکیک میکند، شش کارکرد CSF 2.0 را با زبان عملیاتی توضیح میدهد و نشان میدهد یک تست نفوذ برنامهی وب دقیقاً کدام بخش از این چارچوب را با شواهد قابل ارائه پر میکند.
در یک نگاه
- «چارچوب NIST» معمولاً به NIST CSF 2.0 اشاره دارد که در ۲۶ فوریه ۲۰۲۴ منتشر شد و دامنه‌اش از زیرساخت حیاتی به همهی سازمانها گسترش یافت.
- CSF 2.0 شش کارکرد دارد: GOVERN (تازه‌وارد نسخهی ۲٫۰)، IDENTIFY، PROTECT، DETECT، RESPOND و RECOVER.
- NIST SP 800-115 راهنمای فنی آزمون و ارزیابی است؛ وضعیت آن نهایی و جایگزین‌نشده است، اما تاریخ انتشارش ۳۰ سپتامبر ۲۰۰۸ است.
- CSF یک چارچوب حاکمیتی است نه متدولوژی آزمون؛ پوشش فنی آزمون برنامهی وب را باید از OWASP WSTG گرفت.
چارچوب NIST به کدام سند اشاره دارد؟
NIST (مؤسسه‌ی ملی استانداردها و فناوری آمریکا) ده‌ها سند در حوزه‌ی امنیت منتشر میکند. در گفت‌وگوهای سازمانی، «چارچوب NIST» تقریباً همیشه یکی از این دو است:
- NIST Cybersecurity Framework (CSF) — یک چارچوب حاکمیتی برای سازمان‌دهی برنامهی امنیت. می‌گوید چه چیزهایی باید مدیریت شود، نه چطور آزموده شود.
- NIST SP 800-115 با عنوان کامل Technical Guide to Information Security Testing and Assessment — راهنمای فرایند ارزیابی و آزمون فنی، شامل برنامه‌ریزی، ملاحظات حقوقی، قواعد تعامل و گزارشدهی.
در حاشیه، دو سند دیگر هم مرتب نامشان می‌آید: SP 800-53 برای فهرست کنترل‌های امنیتی و SP 800-63B برای احراز هویت و سیاست گذرواژه — همان سندی که OWASP Top 10:2025 در دسته‌ی A07:2025 صریحاً به آن ارجاع میدهد. اگر می‌خواهید نسخهی مشخصی از SP 800-63 را استناد کنید، ابتدا ویرایش جاری آن را از سایت NIST بررسی کنید؛ این خانواده در حال بازنگری است.
تفکیک این نقشها اهمیت عملی دارد: بسیاری از سازمانها CSF را به‌عنوان چک‌لیست فنی به تیم توسعه می‌دهند و نتیجه‌ی طبیعی‌اش سردرگمی است. جایگاه هر مرجع در متدولوژی تست نفوذ با جزئیات بیشتری تفکیک شده است.
شش کارکرد CSF 2.0 و معنای عملیاتی هرکدام
نسخهی ۲٫۰ در ۲۶ فوریه ۲۰۲۴ منتشر شد. مهمترین تغییر ساختاری، افزودن کارکرد GOVERN به پنج کارکرد نسخهی ۱٫۱ بود — یعنی NIST رسماً پذیرفت که بدون تعیین مالکیت، پاسخگویی و بستر تصمیم‌گیری، پنج کارکرد دیگر روی هوا می‌مانند. تغییر دوم، گسترش دامنهی کاربرد از زیرساختهای حیاتی به همهی سازمانها در هر اندازه و صنعتی بود.
| کارکرد | پرسش محوری | نمونه‌ی خروجی در یک سازمان نرم‌افزاری |
|---|---|---|
| GOVERN (GV) | چه کسی تصمیم میگیرد و پاسخ‌گو است؟ | سیاست امنیت، مالک ریسک برای هر سامانه، آستانه‌ی پذیرش ریسک |
| IDENTIFY (ID) | چه داریم و چه چیزی در خطر است؟ | موجودی دامنه‌ها و APIها، طبقهبندی داده، مدیریت آسیب‌پذیری |
| PROTECT (PR) | چطور جلوی رخداد را می‌گیریم؟ | مجوزدهی سمت سرور، MFA، مقاوم‌سازی پیکربندی، TLS |
| DETECT (DE) | اگر اتفاق بیفتد می‌فهمیم؟ | ثبت رخداد با زمینه‌ی کافی، هشدار قابل اقدام، سامانه‌ی تشخیص نفوذ |
| RESPOND (RS) | چه کسی چه میکند؟ | راهنمای اجرایی پاسخ به رخداد، مسیر ارتباطی، مهار |
| RECOVER (RC) | چطور برمی‌گردیم؟ | پشتیبان آزموده‌شده، بازیابی سرویس، درس‌آموخته |
ترتیب این شش کارکرد، ترتیب زمانی نیست؛ یک چرخه‌ی همزمان است. سازمانی که فقط روی PROTECT سرمایه‌گذاری میکند و DETECT را رها کرده، دقیقاً همان الگویی را تکرار میکند که A09:2025 در OWASP آن را دسته‌ی مستقلی از ریسک می‌داند.
NIST SP 800-115 و فرایند آزمون فنی
SP 800-115 در ۳۰ سپتامبر ۲۰۰۸ منتشر شد، جایگزین SP 800-42 شد و وضعیت فعلی آن نهایی است — نه بازپس‌گرفته و نه جایگزین‌شده، و هیچ پیش‌نویس به‌روزرسانی برای آن اعلام نشده است.
ساختار ارزیابی در این سند سه مرحله دارد:
- برنامه‌ریزی — تعیین دامنه، اهداف، قواعد تعامل، مجوزهای حقوقی و نحوه‌ی نگه‌داری داده‌های حساس کشف‌شده.
- اجرا — در دو گام کشف (شناسایی هدف و تحلیل آن) و حمله (راستی‌آزمایی آسیب‌پذیری با بهره‌برداری کنترل‌شده).
- پس از اجرا — تحلیل، گزارشدهی و پیشنهاد اقدام اصلاحی.
این همان اسکلتی است که فرایند تست نفوذ در عمل روی آن سوار میشود. ارزش امروزی SP 800-115 در بخش حاکمیت آزمون است: چه چیزی مکتوب شود، مجوز چگونه گرفته شود، داده‌ی حساسِ کشف‌شده چطور نگه‌داری و امحا شود، و گزارش چه ساختاری داشته باشد.
«ما بر اساس NIST SP 800-115 تست نفوذ وب انجام می‌دهیم، پس پوشش فنی‌مان کامل است.» این سند نزدیک به هجده سال قدمت دارد و محتوای فنی آزمون برنامه‌های وب مدرن را پوشش نمی‌دهد — نه API، نه SPA، نه معماری ابری. مرجع درست برای پوشش فنی، راهنمای آزمون OWASP است؛ SP 800-115 مرجع فرایند است. ادعای «انطباق با SP 800-115» بدون این تفکیک، در ممیزی فنی دوام نمی‌آورد.
تست نفوذ وب چه شواهدی برای CSF تولید میکند؟
ارزش عملی تست نفوذ برای سازمانی که خود را با CSF سنجیده، تولید شواهد قابل ارائه است. یک ارزیابی امنیتی خوب همزمان چند کارکرد را تغذیه میکند:
| کارکرد CSF | خروجی مستقیم تست نفوذ |
|---|---|
| IDENTIFY | فهرست واقعی دارایی‌های در معرض اینترنت — زیردامنه‌ها، محیط‌های آزمایشی رهاشده، APIهای مستندنشده. تقریباً همیشه بلندتر از فهرستی است که سازمان دارد. |
| PROTECT | راستی‌آزمایی این‌که کنترل‌های ادعاشده واقعاً اجرا می‌شوند: آیا مجوزدهی سمت سرور است یا فقط منوی رابط کاربری پنهان شده؟ آیا MFA در همهی مسیرهای ورود اعمال میشود؟ |
| DETECT | لاگ حمله‌های انجام‌شده در بازهی آزمون. مقایسه‌ی آن با هشدارهای واقعاً تولیدشده، دقیق‌ترین سنجش بلوغ تشخیص است. |
| RESPOND | تمرین واقعی مسیر گزارش و رفع: چه کسی یافته را میگیرد، چقدر طول می‌کشد، و گزارش تست نفوذ چطور به تیکت تبدیل میشود. |
کارکرد DETECT بیشترین بازده پنهان را دارد. در بیشتر ارزیابی‌ها، تیم امنیت پس از پایان کار می‌پرسد «کدام‌یک از این حمله‌ها را دیدید؟» و پاسخ معمولاً ناخوشایند است. همین تمرین ساده، ارزان‌ترین راه سنجش کارکرد تشخیص است — و اگر می‌خواهید آن را ساختارمند کنید، ارزیابی امنیتی چارچوب گسترده‌تری برای آن ارائه میدهد.
چطور CSF را در سازمان پیاده کنیم؟
مسیری که در سازمان‌های متوسط جواب میدهد، از پایین‌ترین هزینه شروع میشود:
- مالکیت را روشن کنید (GOVERN). برای هر سامانه‌ی مهم، یک نام مشخص به‌عنوان مالک ریسک. بدون این، بقیه‌ی مراحل بی‌اثر است.
- موجودی بگیرید (IDENTIFY). فهرست دامنه‌ها، سرویس‌های در معرض اینترنت، مخازن کد و وابستگی‌ها. یک چک‌لیست امنیت سازمانی برای این مرحله کافی است.
- شکاف‌ها را با ریسک وزن‌دهی کنید. نه با شدت فنی خالص، بلکه با ترکیب شدت و ارزش دارایی.
- کنترل‌ها را قابل اثبات کنید (PROTECT/DETECT). هر کنترل باید یک روش راستی‌آزمایی داشته باشد.
- مستقل بسنجید. برای برنامه‌های وب، تست نفوذ وب دقیق‌ترین سازوکار سنجش است؛ و اگر ریشه‌ی یافته‌ها الگوی کدنویسی تیم است، دوره‌ی سازمانی توسعه‌ی امن پایدارتر از رفع موردی عمل میکند.
یک نکته‌ی مهم برای بازار ایران: گواهینامهی انطباق با CSF وجود ندارد. CSF یک چارچوب مرجع است و هر ادعایی دربارهی «صدور گواهی NIST» را باید با احتیاط برخورد کرد. اگر هدف شما اثبات وضعیت امنیتی برای یک ذی‌نفع بیرونی است، آنچه واقعاً به کار می‌آید یک گزارش ارزیابی مستند با شواهد و پوشش آزمون قابل ردیابی است، نه نام یک چارچوب.
پرسش‌های متداول
نسخهی فعلی چارچوب NIST CSF کدام است؟
نسخهی ۲٫۰ که در ۲۶ فوریه ۲۰۲۴ منتشر شد. مهمترین تفاوتش با نسخهی ۱٫۱ افزودن کارکرد GOVERN (در مجموع شش کارکرد بهجای پنج) و گسترش دامنهی کاربرد از زیرساختهای حیاتی به همهی سازمانها است.
تفاوت NIST CSF با ISO 27001 چیست؟
ISO/IEC 27001:2022 یک استاندارد قابل گواهیشدن با الزامات مشخص و پیوست کنترلی (۹۳ کنترل در ۴ مضمون) است. CSF یک چارچوب مرجع داوطلبانه است که ساختار برنامهی امنیت را سازمان میدهد و گواهینامهی انطباق ندارد. بسیاری از سازمانها هر دو را کنار هم استفاده میکنند: CSF برای ساختاردهی و ISO برای ممیزی رسمی.
آیا NIST تست نفوذ سالانه را الزام میکند؟
CSF بازهی زمانی مشخصی برای آزمون تجویز نمیکند؛ رویکردش مبتنی بر ریسک است. الزام صریح بازهی ۱۲ ماهه را در PCI DSS v4.0.1 و بند ۱۱٫۴ میبینید، نه در CSF. SP 800-115 هم فرایند آزمون را توصیف میکند، نه تناوب آن را.
برای تست نفوذ برنامهی وب باید از NIST استفاده کنیم یا OWASP؟
هر دو، اما برای دو کار متفاوت. اسکلت تعامل، مجوزها و گزارشدهی را از SP 800-115 بگیرید و پوشش فنی آزمون را از راهنمای آزمون OWASP. طبقهبندی ریسک هم معمولاً با OWASP Top 10:2025 و CWE انجام میشود و امتیازدهی با CVSS.
کارکرد GOVERN در CSF 2.0 دقیقاً چه چیزی را میخواهد؟
روشن بودن راهبرد، انتظارات و سیاست امنیت سایبری، تعیین نقشها و پاسخگویی، مدیریت ریسک زنجیرهی تأمین و نظارت مدیریتی. به زبان عملی: مشخص باشد چه کسی دربارهی پذیرش یا رفع یک ریسک تصمیم میگیرد و بر پایهی چه معیاری.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.