امنیت سایبری سازمانی با خرید ابزار شروع نمی‌شود. سازمان‌هایی که فقط خرید کرده‌اند، معمولاً چند سامانه‌ی گران دارند که کسی خروجی‌شان را نمیخواند و هیچ‌کس مالک تصمیم‌های ریسک نیست. آنچه کار میکند یک برنامه است: زنجیره‌ای از حاکمیت، موجودی، ارزیابی ریسک، انتخاب کنترل و سنجش مستمر. این مقاله همان زنجیره را با ترتیب اجرایی و معیار پذیرش هر مرحله توضیح میدهد، و در پایان به مدلی می‌پردازد که در تیمهای نرمافزاری بیشترین بازده را داشته: مدل قهرمان امنیت.
در یک نگاه
- ترتیب درست: حاکمیت ← موجودی دارایی ← ارزیابی ریسک ← انتخاب کنترل ← سنجش. جهش از مرحلهی اول به مرحلهی چهارم، شایع‌ترین اشتباه است.
- کنترل‌ها باید به ریسک‌های واقعی نگاشت شوند؛ OWASP Top 10:2025 بهترین نقشه‌ی موجود برای لایه‌ی برنامه است.
- مدل قهرمان امنیت: یک توسعهدهنده در هر تیم به‌عنوان نقطهی تماس امنیت — ارزان‌ترین راه مقیاس‌دادن به تیم کوچک امنیت.
- برنامه‌ای که سنجه ندارد، بودجه‌ی سال بعد را از دست میدهد.
برنامه‌ی امنیت یعنی چه؟
برنامه‌ی امنیت، مجموعه‌ای از تصمیم‌های مکرر و قابل تکرار است، نه مجموعه‌ای از محصولات. سه مؤلفه دارد:
- حاکمیت — چه کسی تصمیم می‌گیرد، بر پایه‌ی چه معیاری، و به چه کسی پاسخ‌گو است.
- فرایند — چطور دارایی شناسایی، ریسک ارزیابی، کنترل انتخاب و اثربخشی سنجیده می‌شود.
- ظرفیت — چه کسی کار را انجام میدهد و با چه مهارتی.
نبود مؤلفه‌ی اول، مشهودترین علامت است: وقتی یافته‌ای با شدت بالا گزارش می‌شود و هفته‌ها هیچ‌کس تصمیم نمی‌گیرد آن را رفع کند یا بپذیرد، مشکل فنی نیست. چارچوب NIST CSF 2.0 دقیقاً به همین دلیل در نسخه‌ی ۲٫۰ کارکرد GOVERN را به‌عنوان کارکرد ششم اضافه کرد.
مؤلفه‌ی سوم هم معمولاً دست‌کم گرفته می‌شود. تیم امنیت سه‌نفره‌ای که باید پاسخ‌گوی ۴۰ توسعهدهنده باشد، بدون مدل توزیع‌شده شکست می‌خورد — بحثی که در بخش قهرمان امنیت به آن برمی‌گردیم. تصمیم میان ساخت تیم داخلی و برونسپاری هم موضوع مستقلی است که در تیم داخلی یا برونسپاری بررسی شده.
موجودی دارایی: مرحله‌ای که همیشه پرش می‌شود
هیچ کنترلی روی دارایی‌ای که نمی‌شناسید اعمال نمی‌شود. موجودی حداقلی که برای یک سازمان نرمافزاری لازم است:
- دامنه‌ها و زیردامنه‌ها، شامل مواردی که برای کمپین‌های قدیمی ساخته شدند و رها شده‌اند؛
- سرویس‌های در معرض اینترنت روی پورت‌های غیرمتعارف؛
- APIها — به‌ویژه آن‌هایی که مستند نیستند و فقط اپلیکیشن موبایل از آن‌ها استفاده میکند؛
- مخازن کد و وابستگی‌های شخص ثالث (پایه‌ی
A03:2025)؛ - حساب‌های سرویس ابری و سطل‌های ذخیره‌سازی؛
- پیمانکاران و شرکای دارای دسترسی.
خروجی این مرحله باید یک جدول زنده باشد، نه یک فایل یک‌باره. هر دارایی دست‌کم سه ستون دارد: مالک، طبقه‌ی داده، و در معرض اینترنت بودن یا نبودن. الگوی عملی این جدول در چک‌لیست امنیت سازمانی آمده است.
«موجودی دارایی داریم، همان فهرست سرورهای تیم زیرساخت است.» فهرست سرور، موجودی دارایی نیست. در بیشتر ارزیابی‌ها، آسیب‌پذیرترین دارایی یک زیردامنه‌ی فراموش‌شده، یک محیط استیجینگ بدون احراز هویت، یا یک API نسخه‌ی قدیمی است که هیچ‌کدام در فهرست سرورها به‌عنوان «سامانه» ثبت نشده‌اند. موجودی باید از دید مهاجم بیرونی ساخته شود، نه از دید نمودار سازمانی.
ارزیابی ریسک بدون پیچیدگی زائد
ارزیابی ریسک لازم نیست به یک پروژه‌ی شش‌ماهه تبدیل شود. حداقل قابل دفاع، برای هر دارایی مهم چهار پرسش است:
- اگر این داده افشا شود، چه اتفاقی می‌افتد؟ (محرمانگی)
- اگر کسی بتواند آن را تغییر دهد چطور؟ (یکپارچگی)
- اگر این سرویس یک روز از دسترس خارج شود چه هزینه‌ای دارد؟ (دسترس‌پذیری)
- چه کسی انگیزه‌ی حمله دارد و با چه سطحی از تلاش؟
حاصل این چهار پاسخ، رتبه‌بندی ساده‌ای است که برای اولویت‌گذاری کافی است. برای سامانه‌های حساس، گام بعدی مدل‌سازی تهدید است: بررسی ساختارمند این‌که در طراحی، چه چیزی می‌تواند اشتباه پیش برود. OWASP در دسته‌ی A06:2025 جمله‌ی روشنی دارد: «یک طراحی ناامن را نمی‌توان با پیاده‌سازی بی‌نقص جبران کرد.»
در امتیازدهی یافتههای فنی، CVSS ابزار متعارف است. نکته‌ی مهم این است که امتیاز پایه به‌تنهایی، ریسک سازمان شما را نشان نمی‌دهد؛ ارزش دارایی و کنترل‌های جبرانی باید در تصمیم وارد شوند.
انتخاب کنترل و نگاشت به ریسک واقعی
کنترل باید از دل ریسک بیرون بیاید، نه از فهرست خرید. این جدول نگاشت متعارف را برای لایه‌ی برنامه نشان میدهد:
| دسته‌ی ریسک | کنترل مؤثر | کنترل کم‌اثر یا اشتباه |
|---|---|---|
A01:2025 کنترل دسترسی شکسته | مجوزدهی متمرکز سمت سرور، رد پیش‌فرض، بررسی مالکیت رکورد | پنهان‌کردن گزینه در رابط کاربری؛ شناسه‌های تصادفی به‌جای بررسی مجوز |
A02:2025 پیکربندی نادرست | فرایند مقاوم‌سازی تکرارپذیر و یکسان در همه‌ی محیط‌ها | مقاوم‌سازی دستی فقط روی تولید |
A03:2025 زنجیره‌ی تأمین نرم‌افزار | SBOM، رصد CVE، دریافت از منبع رسمی با بررسی امضا | به‌روزرسانی سالانه‌ی وابستگی‌ها |
A05:2025 تزریق | کوئری پارامتری، اعتبارسنجی مثبت سمت سرور، SAST در خط لوله | فیلترکردن کلیدواژه‌های ورودی |
A07:2025 نقص احراز هویت | MFA، مدیریت نشست سمت سرور، بررسی گذرواژه در برابر فهرست‌های افشاشده | الزام تعویض دورهای گذرواژه |
A09:2025 ثبت و هشدار | ثبت رخداد با زمینه‌ی کافی + هشدار متصل به راهنمای اجرایی | جمع‌آوری لاگ بدون هیچ قاعده‌ی هشدار |
ستون سوم را جدی بگیرید؛ بیشتر بودجه‌های هدررفته آنجا خرج می‌شوند. اثربخشی این کنترل‌ها را هم نمی‌شود با فرض سنجید — باید آزمون شود، و برای برنامه‌های وب سازوکار آن تست نفوذ وب است.
مدل قهرمان امنیت
هیچ تیم امنیتی به اندازه‌ی تیم توسعه بزرگ نمی‌شود. مدلی که این عدم‌تقارن را حل میکند، قهرمان امنیت (Security Champion) است: در هر تیم توسعه، یک عضو با علاقه‌ی بیشتر به امنیت، نقطهی تماس و مرجع اول می‌شود.
نقش قهرمان امنیت چیست؟
- بازبینی اولیهی تغییرات حساس — احراز هویت، مجوزدهی، آپلود فایل، پرداخت؛
- پرسیدن پرسشهای امنیتی در جلسه‌ی طراحی، پیش از نوشتن کد؛
- ترجمهی یافتههای گزارش ارزیابی به تیکت قابل اجرا برای تیم خودش؛
- انتقال الگوهای امن به بقیه‌ی اعضا.
نقش قهرمان امنیت چه نیست؟
او متخصص امنیت تماموقت نیست، مسئول رفع همه‌ی یافته‌ها نیست، و جایگزین ارزیابی مستقل هم نیست. سه شرط موفقیت این مدل: زمان رسمی در ظرفیت هفتگی، آموزش واقعی نه یک جلسه‌ی معرفی، و پشتیبانی مستقیم از تیم امنیت.
شرط دوم بیشترین شکست را می‌بیند. آموزشی که به تمرین روی کد واقعی همان تیم متصل نباشد، ظرف چند هفته فراموش می‌شود. مسیر یادگیری و منابع در آموزش امنیت سایبری آمده و برای تیمهای توسعه، دوره‌ی سازمانی توسعه‌ی امن دقیقاً برای همین شکاف طراحی شده است.
سنجش: از کجا بفهمیم برنامه کار میکند؟
سنجه‌های کم‌ارزش را کنار بگذارید: تعداد حملههای مسدودشده توسط WAF، تعداد ایمیل‌های فیشینگ فیلترشده و تعداد آسیب‌پذیری‌های گزارش‌شده توسط اسکنر، هیچ‌کدام درباره‌ی بلوغ برنامه چیزی نمی‌گویند. سنجههایی که واقعاً تصمیم‌ساز‌اند:
- میانهی زمان رفع به تفکیک شدت — روند آن مهم‌تر از عدد مطلق است؛
- نسبت یافتههای تکراری در دو ارزیابی متوالی — بالا بودنش یعنی رفع، ریشه‌ای نبوده؛
- پوشش موجودی — چند درصد داراییهای در معرض اینترنت مالک مشخص دارند؛
- نرخ تشخیص — چند درصد از حملههای تیم آزمون هشدار تولید کرد؛
- پوشش MFA روی دسترسی‌های اداری.
سنجه‌ی دوم بیشترین اطلاعات را میدهد. اگر یافتههای ارزیابی امسال همان‌های پارسال باشند، مشکل در گزارش نیست؛ در فرایند رفع است. برای ساختارمند‌کردن این چرخه مدیریت آسیب‌پذیری و برای دید کلان‌تر ارزیابی امنیتی نقطهی ادامه‌ی این مقاله‌اند.
پرسشهای متداول
برنامه‌ی امنیت سایبری سازمانی را از کجا شروع کنیم؟
از تعیین مالکیت و موجودی دارایی. تا مشخص نباشد چه کسی درباره‌ی ریسک تصمیم می‌گیرد و سازمان دقیقاً چه سرویس‌هایی در معرض اینترنت دارد، خرید هر ابزاری زودهنگام است. این دو گام هزینهی مالی تقریباً صفر دارند و بیشترین اثر را می‌گذارند.
برای یک شرکت نرمافزاری ۵۰ نفره چند نفر تیم امنیت لازم است؟
عدد ثابتی وجود ندارد و به سطح ریسک و تعداد سامانهها بستگی دارد. الگویی که در این اندازه معمولاً جواب میدهد، یک نفر مسئول تماموقت امنیت بهعلاوهی مدل قهرمان امنیت در تیمهای توسعه است، همراه با برونسپاری ارزیابیهای تخصصی دورهای.
قهرمان امنیت دقیقاً چه کاری انجام میدهد؟
یک توسعهدهنده در هر تیم که نقطهی تماس امنیت است: بازبینی اولیهی تغییرات حساس، طرح پرسشهای امنیتی در مرحلهی طراحی، و ترجمهی یافتههای ارزیابی به کار قابل اجرا. او متخصص تماموقت امنیت نیست و باید زمان رسمی و آموزش واقعی دریافت کند.
چه سنجههایی برای گزارش به مدیریت مناسب است؟
میانهی زمان رفع به تفکیک شدت، نسبت یافتههای تکراری بین دو ارزیابی، درصد داراییهای دارای مالک مشخص، نرخ تشخیص حملههای آزمون، و پوشش MFA. اینها روند نشان میدهند؛ برخلاف تعداد حملههای مسدودشده که فقط حجم ترافیک را منعکس میکند.
ابزار بخریم یا اول فرایند بسازیم؟
اول فرایند. ابزاری که خروجیاش را کسی نمیخواند و مالکی برای اقدام ندارد، هزینهی جاری بدون بازده است. ترتیب درست این است که ابتدا مشخص شود چه تصمیمی باید گرفته شود و چه دادهای برای آن لازم است، سپس ابزاری که آن داده را تولید میکند انتخاب شود.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.