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

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

🔍 گواهی امنیتی واقعاً چه چیزی را تأیید می‌کند؟

برای بیشتر مردم، واژهٔ «گواهی‌شده» مثل یک حکم نهایی به نظر می‌رسد؛ یعنی محصول بررسی شده و همهٔ معیارهای لازم را دارد. اما باختینا می‌گوید واقعیت این‌گونه نیست.

📜 Common Criteria؛ ادعای فروشنده در یک چارچوب مشخص

گواهی CC می‌گوید یک آزمایشگاه معتبر، محصولی معین را در پیکربندی معین، در برابر ادعاهای امنیتی‌ای ارزیابی کرده که خود فروشنده در سندی به نام Security Target نوشته است. این سند اغلب بر پایهٔ یک Protection Profile برای همان نوع محصول، مانند کارت‌های هوشمند، تنظیم می‌شود. پس «برآورده‌کردن معیارها» در عمل یعنی «برآورده‌کردن معیارهایی که فروشنده ادعا کرده، در دامنه‌ای که تعریف شده». گواهی همچنین تأیید می‌کند که ارزیابی با فرایند استاندارد و در سطح تضمین اعلام‌شده (EAL) انجام شده است. وعدهٔ گواهی دربارهٔ ادعاها و فرایند است، نه دربارهٔ امن‌بودن کلی محصول.

🔐 FIPS 140؛ داستان یک ماژول رمزنگاری

FIPS 140 موضوع دیگری است. این استاندارد یک ماژول رمزنگاری — یعنی سخت‌افزار، نرم‌افزار یا میان‌افزاری که کار رمزنگاری را انجام می‌دهد — را در برابر الزامات FIPS 140 و در یکی از چهار سطح امنیتی اعتبارسنجی می‌کند. وعدهٔ آن فقط دربارهٔ همان ماژول و در مرزهای تعریف‌شدهٔ آن است و دربارهٔ برنامه یا سامانهٔ پیرامونش چیزی نمی‌گوید.

⚠️ چهار برداشت نادرست رایج

🚫 «هیچ آسیب‌پذیری‌ای ندارد»: گواهی چنین چیزی نمی‌گوید. آسیب‌پذیری‌های ROCA، Minerva و TPM-Fail همه در محصولات گواهی‌شده یافت شدند، بعضی حتی در سطوح تضمین بالا.
🧩 «کل محصول پوشش داده شده»: دامنه می‌تواند برخی قابلیت‌ها را کنار بگذارد. نمونه‌ای که پژوهشگران دیده‌اند یک دوربین شبکهٔ دارای گواهی CC بود که در آن فرض شده بود رابط شبکه قابل اعتماد است و احتمالاً هرگز آزمون نشده بود.
📅 «همان نسخه‌ای که می‌خرم، همان نسخهٔ آزمون‌شده و معتبر است»: گواهی CC به یک پیکربندی ثابت تعلق دارد و اعتبار محدودی دارد؛ معمولاً پنج سال که پس از آن بایگانی می‌شود.
📈 «سطح بالاتر یعنی امن‌تر»: سطح بالاتر فقط می‌گوید محصول با دقت و عمق بیشتری بررسی شده است. در داده‌های این تیم، محصولات با سطح بالاتر آسیب‌پذیری‌های کم‌شدت‌تری داشتند، اما تعدادشان به‌طور محسوس کمتر نبود.

«گواهی می‌گوید در یک نقطه از زمان چه چیزی و چگونه ارزیابی شده است؛ نمی‌گوید از آن زمان به بعد چه چیزی کشف یا چه چیزی تغییر کرده.»

📊 شش از ده آسیب‌پذیری، بعد از تاریخ گواهی

در تحلیل سال ۲۰۲۴ این تیم، حدود شش مورد از هر ده آسیب‌پذیری که به محصولات گواهی‌شده نسبت داده شده بود — بدون در نظر گرفتن کارت‌های هوشمند — پس از تاریخ صدور گواهی افشا شده بودند. یک سند گواهی به‌تنهایی نمی‌تواند بگوید گواهی هنوز فعال است یا نه، و نمی‌تواند محصول را با دو گزینهٔ دیگر فهرست خرید مقایسه کند؛ این پرسش‌ها به چند سند مختلف نیاز دارند.

🧰 sec-certs و SCRUTINY؛ وقتی اسناد قابل جست‌وجو می‌شوند

باختینا دو ابزار متن‌باز آزمایشگاه خود را معرفی می‌کند. sec-certs یک ابزار و وب‌سایت متن‌باز است که اسناد عمومی گواهی را به مجموعه‌داده‌ای قابل جست‌وجو و به‌هم‌پیوسته تبدیل می‌کند؛ دامنهٔ آن Common Criteria، FIPS 140 و EUCC را در بر می‌گیرد. این ابزار هر هفته اسناد را از درگاه‌های رسمی جمع‌آوری می‌کند، داده‌های کلیدی را استخراج می‌کند، گواهی‌ها را به آسیب‌پذیری‌های شناخته‌شده پیوند می‌دهد و تشخیص می‌دهد کدام گواهی‌ها به یکدیگر ارجاع می‌دهند. می‌توان از آن در وب‌سایت یا به‌صورت کتابخانهٔ پایتون استفاده کرد.

انگیزهٔ ساخت این ابزار ساده بود: همهٔ این شواهد عمومی‌اند اما در عمل غیرقابل استفاده؛ پراکنده در هزاران فایل PDF بلند روی درگاه‌های ملی متعدد، بدون شناسهٔ مشترک و بدون پیوند با داده‌های آسیب‌پذیری. ایدهٔ اولیه از پژوهشگران مرکز پژوهش رمزنگاری و امنیت (CRoCS) آمد که دقیقاً همین را در جریان افشای ROCA و Minerva لازم داشتند.

👥 چه کسانی اول سراغ این ابزار می‌روند؟

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

❓ پرسشی که باید از فروشنده پرسید

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

✅ جمع‌بندی

گواهی امنیتی جایگاه مهمی دارد، اما جای تصمیم‌گیری را نمی‌گیرد. آنچه خریدار باید بداند این است که چه نسخه و چه پیکربندی‌ای ارزیابی شده، چه چیزی خارج از دامنه مانده و گواهی امروز چه وضعیتی دارد. پرسیدن همین چند نکته از فروشنده، بیش از تکیه بر واژهٔ فریبندهٔ «گواهی‌شده» به تصمیم درست نزدیک‌تر است. 🔎

منبع: Help Net Security

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