خواندن ۴ دقیقه·۱۵ روز پیش

KPI در امنیت اطلاعات: آنچه فکر می‌کنیم می‌دانیم، و آنچه واقعاً نمی‌دانیم

در اغلب سازمان‌ها، وقتی صحبت از KPIهای امنیت اطلاعات می‌شود، تصور غالب این است که مسئله حل شده است. داشبوردها پر از عددند، گزارش‌ها منظم تولید می‌شوند و جلسات مدیریتی با نمودارهایی از Incident، Alert و Patch Rate برگزار می‌شود. اما از دیدگاه یک CISSP یا ISSMP، سؤال اصلی این نیست که «آیا KPI داریم؟» بلکه این است که آیا KPIهای ما واقعاً تصمیم‌ساز هستند یا فقط توجیه‌گر؟

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

KPI با Metric چه تفاوتی دارد؟

Metric پاسخ می‌دهد: چه اتفاقی افتاده است؟ ولی KPI پاسخ می‌دهد: حالا چه تصمیمی باید بگیریم؟

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

چالش حرفه‌ای اینجاست:اگر فردا این عدد صفر شود، چه چیزی در سازمان تغییر می‌کند؟ اگر پاسخ مشخصی ندارید، آن شاخص KPI نیست،حتی اگر در گزارش CISO آمده باشد.

مشکل اصلی: KPIهای پسینی (Lagging) در برابر KPIهای پیش‌بینی‌کننده (Leading)

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

نمونه‌های رایج KPIهای پسینی عبارتند از : تعداد Incident در ماه،تعداد نفوذ موفق،حجم داده نشت‌کرده

این‌ها برای گزارش‌دهی خوب‌اند، اما برای مدیریت کافی نیستند.

در مقابل، KPIهای پیش‌بینی‌کننده سعی می‌کنند احتمال موفقیت تهدید را قبل از وقوع Incident نشان دهند. مثال‌های حرفه‌ای‌تر عبارتند از :درصد دارایی‌هایی که مالک ریسک مشخص ندارند،میانگین زمان شناسایی drift ،معماری نسبت به baseline،درصد کنترل‌های امنیتی که بدون سناریوی تهدید معتبر پیاده‌سازی شده‌اند،نسبت Detection Coverage به Attack Surface واقعی (نه اسمی)

این KPIها مستقیماً به احتمال حادثه اشاره می‌کنند، نه فقط نتیجه آن.

KPI بدون Context، یک عدد بی‌معناست

ISO 31000 به‌صراحت می‌گوید که ریسک بدون Context بی‌معناست؛ همین منطق دقیقاً در مورد KPI هم صدق می‌کند. عدد MTTR = 4 ساعت، ذاتاً نه خوب است و نه بد. معنا زمانی شکل می‌گیرد که بدانیم:

مأموریت چیست؟ وتحمل ریسک چقدر است؟وپیامد توقف سرویس چیست؟

در یک سامانه بانکی Real-Time، MTTR چهار ساعت فاجعه است. در یک سیستم آرشیوی آفلاین، شاید کاملاً قابل‌قبول باشد. بنابراین KPI واقعی باید به‌طور ضمنی یا صریح بگوید«با توجه به این مأموریت و این سطح Risk Appetite، این عدد قابل‌قبول است یا نه.»

اگر KPI شما این قضاوت را ممکن نمی‌کند، در واقع تصمیم‌سازی نمی‌کند.KPIهایی که به مأموریت وصل نیستند، در بودجه شکست می‌خورنداز دیدگاه ISSMP، هر KPI باید بتواند از خودش در جلسه بودجه دفاع کند. یعنی باید بتوان نشان داد:

این شاخص چگونه از Revenue محافظت می‌کند؟وچگونه از Reputation سازمان دفاع می‌کند؟وچگونه تداوم مأموریت (Mission Continuity) را تقویت می‌کند؟

KPIهایی که فقط «امنیت را بیشتر می‌کنند» اما نتوانند اثرشان را بر مأموریت توضیح دهند، معمولاً به ابزارمحوری منجر می‌شوند: IDS، SIEM، EDR، بدون اینکه کسی بداند کدام واقعاً ریسک را کاهش داده است.

حقیقت تلخ: KPI خوب، دشمن کنترل بد است

یکی از چیزهایی که معمولاً گفته نمی‌شود این است که KPI واقعی برای خیلی از سازمان‌ها تهدید است. چرا؟ چون KPI خوب کنترل‌های نمایشی را افشا می‌کند ابزارهای کم‌اثر ولی پرهزینه را بی‌دفاع می‌گذاردROI امنیتی را شفاف می‌کند

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

KPI و RMF: پیوندی که اغلب نادیده گرفته می‌شود

در NIST RMF، KPIها نباید فقط در Tier 3 (سیستم‌ها) باقی بمانند. KPI بالغ: