بحث درباره‌ی اهمیت امنیت سایبری معمولاً با آمارهای بی‌منبع و جمله‌های ترسناک شروع می‌شود و دقیقاً به همین دلیل کار نمی‌کند. مدیری که تصمیم میگیرد، به آمار جهانی واکنش نشان نمی‌دهد؛ به هزینهی قابل نسبت‌دادن به سازمان خودش واکنش نشان میدهد. این مقاله عمداً هیچ آمار ساختگی نقل نمی‌کند و فقط از نمونه‌های مستند و استدلال کیفی استفاده میکند تا بتوانید همان استدلال را در جلسه‌ی بودجه تکرار کنید.
در یک نگاه
- هزینهی رخنه فقط فنی نیست: توقف عملیات، جریمه‌ی نظارتی، از دست رفتن قرارداد و زمان مدیریت ارشد.
- OWASP نمونهی مستند نقل میکند: جریمه‌ی ۲۰ میلیون پوندی برای رخنه‌ی داده‌ی پرداخت یک شرکت هواپیمایی، و رخنهای که ۳٫۵ میلیون کودک را درگیر کرد و از ۲۰۱۳ کشفنشده ماند.
- در داده‌ی OWASP Top 10:2025، ۱۰۰٪ برنامه‌های آزموده‌شده شکلی از کنترل دسترسی شکسته داشته‌اند.
- قاب‌بندی درست: امنیت را به تصمیم و پیامد وصل کنید، نه به احتمال و ترس.
چرا استدلال رایج شکست می‌خورد
سه الگوی ناکارآمد که مرتب تکرار میشوند:
- آمار بدون منبع. «۶۰٪ کسب‌وکارهای کوچک پس از حمله تعطیل میشوند» جمله‌ای است که همه شنیده‌اند و تقریباً هیچ‌کس منبعش را نمیداند. اولین مدیری که منبع را بپرسد، اعتبار کل ارائه را از بین می‌برد.
- احتمال به‌جای پیامد. کسی نمیداند احتمال حمله به سازمان شما چقدر است. اما همه می‌توانند بگویند اگر سامانه‌ی سفارش‌گیری یک روز از کار بیفتد چه اتفاقی می‌افتد.
- زبان فنی. «آسیب‌پذیری تزریق SQL داریم» برای مدیر مالی معنایی ندارد؛ «کل پایگاه‌داده‌ی مشتریان از طریق یک فرم عمومی قابل استخراج است» معنا دارد.
جایگزین، ساده است: به‌جای بحث درباره‌ی تهدید، درباره‌ی دارایی و پیامد صحبت کنید. این همان منطقی است که برنامه‌ی امنیت سازمانی بر پایهی آن ساخته می‌شود.
هزینهی واقعی یک رخنه از چه اجزایی تشکیل می‌شود؟
بدون نقل عدد ساختگی، می‌توان فهرست هزینه‌ها را دقیق نوشت. هر سازمانی می‌تواند این جدول را با اعداد خودش پر کند — و همین کار، مؤثرترین بخش گفت‌وگوی بودجه است:
| دسته‌ی هزینه | چه چیزی را شامل می‌شود | چطور تخمین بزنیم |
|---|---|---|
| توقف عملیات | قطعی سرویس، توقف فروش، بازگرداندن از پشتیبان | درآمد ساعتی × ساعت‌های تخمینی قطعی |
| پاسخ به رخداد | تحلیل، پاک‌سازی، بازسازی زیرساخت، مشاور بیرونی | نرخ روزانه × نفر-روز تخمینی |
| نظارتی و قراردادی | جریمه، تعهدات قراردادی به مشتری سازمانی | بندهای موجود در قراردادهای جاری |
| از دست رفتن کسبوکار | قرارداد ازدست‌رفته، مشتری خارج‌شده | ارزش قراردادهایی که ارزیابی امنیتی می‌خواهند |
| زمان مدیریت | هفته‌های مدیریت ارشد که صرف بحران می‌شود | پرهزینهترین قلم پنهان |
| بازسازی اعتماد | ارتباطات، تخفیف جبرانی، ممیزی مجدد | کیفی، اما واقعی |
ردیف آخر ستون سوم مهم‌ترین نکته را دارد: بسیاری از قراردادهای سازمانی امروز شرط ارائه‌ی گزارش ارزیابی امنیتی دارند. برای شرکتی که در حال مذاکره با یک مشتری بزرگ است، این ردیف نه هزینهی احتمالی، بلکه درآمد از دست‌رفته‌ی قطعی است. جزئیات این استدلال در مزایای تست نفوذ آمده است.
آنچه داده‌های مستند نشان می‌دهند
به‌جای آمار بی‌منبع، این نمونه‌ها را OWASP در متن رسمی Top 10:2025 نقل کرده است:
- در دسته‌ی
A09:2025: رخنهای در یک ارائه‌دهنده‌ی طرح سلامت کودکان که ۳٫۵ میلیون کودک را تحت تأثیر قرار داد و از سال ۲۰۱۳ کشف نشده بود، چون نه ثبت رخداد کافی وجود داشت و نه پایش. کشف نهایی هم با اطلاع یک نهاد بیرونی انجام شد. - در همان دسته: یک شرکت هواپیمایی اروپایی با رخنهای شامل بیش از ۴۰۰٬۰۰۰ رکورد پرداخت مشتریان، که به جریمه‌ی نظارتی ۲۰ میلیون پوندی منجر شد.
- در دسته‌ی
A03:2025: به‌روزرسانی آلوده‌ی یک تأمین‌کننده‌ی مورد اعتماد در سال ۲۰۱۹ که حدود ۱۸٬۰۰۰ سازمان را آلوده کرد، و رخدادی در سال ۲۰۲۵ که با نرم‌افزار کیف پول دستکاری‌شده به سرقت ۱٫۵ میلیارد دلار منجر شد.
و یک عدد که مستقیماً به کار سازمان شما می‌آید: در مجموعه‌داده‌ی OWASP برای Top 10:2025، ۱۰۰٪ برنامه‌های آزموده‌شده شکلی از کنترل دسترسی شکسته داشته‌اند. این یعنی احتمال این‌که برنامه‌ی شما استثنا باشد، بر پایهی داده‌ی موجود، بسیار پایین است — و این استدلالی است که برخلاف آمارهای رایج، منبع اول‌دست دارد. توضیح این دسته در کنترل دسترسی شکسته آمده است.
«ما کوچکیم و داده‌ی ارزشمندی نداریم، پس هدف نیستیم.» بیشتر حملات وب هدفمند نیستند؛ اسکن انبوه اینترنت برای یافتن الگوهای آسیبپذیر شناختهشده است. مهاجم پیش از رسیدن به سرور شما نمیداند و برایش مهم نیست که چه کسی هستید. ضمناً «داده‌ی ارزشمند» را دست‌کم می‌گیرید: فهرست مشتریان، اعتبارنامه‌های بازاستفاده‌شده، و خودِ سرور به‌عنوان بستری برای میزبانی صفحه‌ی فیشینگ یا ارسال هرزنامه، هر سه برای مهاجم ارزش دارند.
قاب‌بندی برای مدیر مالی و مدیرعامل
سه جمله‌ای که در جلسه‌ی مدیریت کار می‌کنند، این ساختار را دارند:
- دارایی مشخص + پیامد مشخص. «سامانه‌ی پرداخت، داده‌ی کارت مشتری را پردازش میکند و از ۱۸ ماه پیش ارزیابی نشده است.»
- تصمیم مشخص. «دو گزینه داریم: ارزیابی این سامانه در این چرخه، یا پذیرش مکتوب این ریسک توسط مالک آن.»
- هزینهی مقایسه‌ای. «هزینهی ارزیابی از هزینهی یک روز توقف این سرویس کمتر است.»
گزینه‌ی دوم در بند دوم، مؤثرترین ابزار است: پذیرش مکتوب ریسک. وقتی روشن شود که نپرداختن هزینهی ارزیابی یعنی امضای پذیرش ریسک توسط یک فرد مشخص، ماهیت گفت‌وگو تغییر میکند. این ساختار پاسخ‌گویی، همان چیزی است که کارکرد GOVERN در چارچوب NIST به دنبال آن است.
برای برآورد ستون هزینه هم لازم نیست حدس بزنید؛ عوامل تعیین‌کننده‌ی قیمت یک ارزیابی در هزینهی تست نفوذ تفکیک شده است.
امنیت به‌عنوان مزیت، نه فقط هزینه
سه موقعیتی که در آن امنیت مستقیماً درآمدساز است — و در بازار ایران هر سه در حال پررنگ‌شدن‌اند:
- فروش سازمانی. مشتری بزرگ، پیش از امضا پرسش‌نامه‌ی امنیتی می‌فرستد یا گزارش ارزیابی می‌خواهد. نداشتن پاسخ، یعنی طولانی‌شدن یا از دست رفتن چرخه‌ی فروش.
- سرعت توسعه. تیمی که الگوهای امن را در مرحله‌ی طراحی رعایت میکند، در پایان چرخه با فهرست بلند یافته روبه‌رو نمی‌شود. هزینهی رفع یک نقص طراحی پس از انتشار، چند برابر هزینهی آن در مرحله‌ی طراحی است — و برخی نقص‌های طراحی اصلاً با پیاده‌سازی درست جبران نمی‌شوند؛ همان چیزی که
A06:2025می‌گوید. - اعتماد کاربر. در سرویس‌هایی که کاربر داده‌ی حساس وارد میکند، سابقه‌ی رخنه هزینهی جذب مشتری را بالا می‌برد.
نتیجه‌ی عملی این بحث یک جمله است: امنیت را به‌عنوان بخشی از کیفیت محصول قاب‌بندی کنید، نه به‌عنوان بیمه. برای سنجش وضعیت فعلی، تست نفوذ وب ملموس‌ترین نقطه‌ی شروع است و اگر هنوز مطمئن نیستید سازمان شما به چه سطحی نیاز دارد، مشاوره‌ی اولیه گفت‌وگوی کم‌هزینه‌تری است.
پرسش‌های متداول
چرا امنیت سایبری برای کسبوکار مهم است؟
چون هزینهی یک رخنه فقط فنی نیست: توقف عملیات، هزینهی پاسخ به رخداد، تعهدات قراردادی و نظارتی، از دست رفتن قرارداد و زمان مدیریت ارشد. در بسیاری از سازمانها، پرهزینهترین قلم همان زمان مدیریتی و کسبوکار از دسترفته است، نه بازسازی فنی.
چطور به مدیرعامل توضیح دهیم که به بودجه‌ی امنیت نیاز داریم؟
با دارایی و پیامد شروع کنید، نه با آمار. مشخص کنید کدام سامانه چه داده‌ای دارد، آخرین ارزیابی کی بوده، توقفش چه هزینه‌ای دارد و چه تصمیمی لازم است. گزینه‌ی جایگزین را هم صریح بگذارید: پذیرش مکتوب ریسک توسط مالک آن سامانه.
سازمان کوچک هم هدف حمله قرار میگیرد؟
بله، چون بیشتر حملات وب هدفمند نیستند و بر پایهی اسکن انبوه اینترنت برای یافتن الگوهای آسیبپذیر شناختهشده انجام میشوند. مهاجم پیش از رسیدن به سرور نمیداند سازمان چقدر بزرگ است و خودِ سرور هم برای میزبانی فیشینگ یا ارسال هرزنامه ارزش دارد.
هزینهی امنیت را چطور توجیه کنیم وقتی هیچ اتفاقی نیفتاده؟
با تغییر معیار از «حملهی رخداده» به «توانایی تشخیص». پرسش درست این است که اگر رخنهای رخ داده بود، چقدر طول میکشید تا متوجه شوید. نمونهی مستند OWASP از رخنهای که سالها کشفنشده باقی ماند، دقیقاً همین شکاف را نشان میدهد.
از کجا شروع کنیم؟ ابزار بخریم یا ارزیابی کنیم؟
ابتدا بدانید چه دارید و وضعیت واقعیاش چیست. یک ارزیابی روی سامانههای در معرض اینترنت، تصویری واقعی و اولویتدار میدهد که تصمیمهای خرید بعدی را هدفمند میکند؛ خرید ابزار پیش از این تصویر، معمولاً هزینهی جاری بدون بازده است.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حملهی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.