به گزارش روابط عمومی سازمان نظام صنفی رایانه‌ای استان تهران، نشست‌های کارگروه تحول دیجیتال دولت با حضور با حضور معاون توسعه و ارزیابی صنعت افتا، برگزار شد.

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

مجید عسکرزاده معاون توسعه و ارزیابی صنعت افتا، در توضیح فرآیند صدور این گواهی گفت: «گواهی افتا در حوزه نرم‌افزار در دسته محصولات و خدمات صادر می‌شود. حوزه خدمات شامل نصب و پشتیبانی نرم‌افزارهای مبتنی بر محتوا است که تمام نرم‌افزارهای CMS، BI، اتوماسیون، ERP و … را پوشش می‌دهد.»

عسکرزاده با تأکید بر این نکته که در مرکز افتا فقط ارزیابی امنیتی انجام می‌شود، اظهار داشت: «ارزیابی عملکردی نرم‌افزار در سازمان فناوری اطلاعات انجام شده و سپس ارزیابی امنیتی به مرکز افتا ارجاع می‌شود.»

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

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

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

عسکرزاده با تاکید بر موکول نکردن تهیه زونکن اعتباری به مرحله پایان فرآیند صدور گواهی، بیان کرد: «متقاضیان اخذ گواهی افتا می‌توانند با شروع فرآیند آزمایش، به طور هم‌زمان تهیه زونکن اعتباری را هم شروع کنند. چرا که پس از پایان ارزیابی آزمایشگاه، زونکن اعتباری هم باید به سازمان فناوری اطلاعات ارائه شود تا گواهی افتا صادر شود.»

سپس حاضران در نشست پرسش‌های خود در خصوص اخذ گواهی افتا را مطرح که توسط معاون توسعه و ارزیابی صنعت افتا پاسخ داده شد.

تست نفوذ (OWASP) چه تفاوتی با گواهی افتا دارد؟ چرا نمی‏توان این تست را جایگزین گواهی افتا کرد؟

• بخش زیادی از این روندها باهم اشتراک دارند؛ ولی لزوماً همه تست‌هایی که هنگام ارزیابی امنیتی گواهی افتا انجام می‌شود، در تست نفوذ انجام نمی‌شوند. برای مثال اینکه آیا لاگ متناسب در سیستم تولید می‏شود؟ آیا مدیریت دسترسی‌ها هم بررسی می‌شوند؟ در فرآیند تست نفوذ معمولاً تست‌ها در حد کاربری با پایین‌ترین سطح دسترسی انجام می‌شود و بررسی‌ها برای کاربرهای با دسترسی بالاتر انجام نمی‌شود.

در ارزیابی امنیتی محصول، دو رویکرد وجود دارد؛ یکی اینکه آیا محصول کارکردهای امنیتی لازم را دارد؟ آیا محصول دارای آسیپ‌پذیری است؟ آیا کارکردهای امنیتی به درستی در محصول پیاده شده‌اند؟

تست نفوذ تنها بخشی از این رویکردها را پوشش می‌دهد و به همین دلیل گواهی‌های تست نفوذ برای افتا قابل اتکا و مورد قبول نیست. تست نفوذ یک مرحله از کار است که در حداقل استانداردهای گواهی افتا نمی‌گنجد.

چرا در مورد نرم‌افزارهایی که در زیرساخت‌های حساس و حیاتی استفاده نمی‌‌شوند، سخت‌گیری یکسانی وجود دارد؟

• دسته‌بندی‌هایی در خصوص دستگاه‏ها طی ۱۵ سال اخیر وارد حوزه ادبیات امنیتی شده‌اند. در یک دسته‏بندی دستگاه‌ها به سه دسته حیاتی، حساس و مهم تقسیم شده که مورد استفاده سازمان پدافند است. در تقسیم‌بندی دوم، دستگاه‏ها به دو دسته دستگاه‌های زیرساختی و غیر زیرساختی تفکیک شده که در نظام پیشگیری و مقابله مورد استفاده قرار می‌گیرند. در ارزیابی امنیتی افتا، محصول مستقل از محیط کاربرد و منفک از محیط عملیاتی، ارزیابی می‌شود و این خود دستگاه استفاده‏کننده است که تصمیم می‌گیرد در کجا گواهی امنیت محصول نیاز است و در کجا نیازی به آن ندارد.

چرا بعد از انجام تغییرات جزئی و ارائه نسخه‌های جدید نرم‌افزار، فرآیند ارزیابی مجدداً باید به‌طور کامل طی شود؟

• خیر؛ روند ارزیابی برای نسخ جدید نرم‌افزار این چنین نیست. در مرکز افتا، یک فرآیند تداوم گواهی امنیت نرم افزار با عنوان سند تغییرات، پیش‌بینی شده است که مخصوص تغییر نسخ است. این سند هم با همکاری کمیسیون‌های نرم‌افزاری سازمان نظام صنفی رایانه‏ای قابل بازبینی است تا فرآیند تمدید گواهی برای کسانی که تغییر نسخه دارند، آسان‌تر شود.

پر کردن مستندات لازم پر چالش است و مساله اصلی که رفع باگ‌ها است در مقابل مستندسازی به مساله فرعی تبدیل می شود.

• ادبیات سند امنیتی که بر اساس استاندارد ۱۵۴۰۸ تبیین شده برای برخی شرکت‌های تولیدکننده نرم‌افزار روشن نبود. به همین دلیل برای قابل فهم‌تر شدن این سند و ساده‌تر کردن مستندسازی، در گام اول آن را به چهار سند تبدیل کردیم که همان سند را با ادبیات روان‌تری از شرکت‌ها بخواهیم. دوتا از آن سندها هم تک‌برگ هستند. یکی سند راهنمای محصول و یکی هم سند امنیتی که به چک‏لیست تبدیل شده است. گام دوم این ساده‌سازی را هم می‌توانیم با مشارکت سازمان نظام صنفی رایانه‌ای و آزمایشگاه‌ها برداریم. اگر روی چک‌لیست هم ابهاماتی وجود دارد، این آمادگی وجود دارد که ادبیات این سند هم با همکاری آزمایشگاه‌ها و کمیسیون‌های نرم‌افزاری سازمان نظام صنفی رایانه‌ای، روان‌تر و آشناتر شود.
• همچنین در مرکز افتا این آمادگی برای شرح فرآیند ارزیابی و همچنین آموزش پیاده‌سازی الزامات امنیتی در محصول، وجود دارد. تا از این طریق، این موضوع که در هر بند از الزامات امنیتی دقیقا چه چیزی نیاز است، روشن‌تر شود.

بسیاری از شرکت‌ها در بخش مستندسازی به آموزش نیاز دارند. گاهی مستندات توسط خود آزمایشگاه تکمیل می‌شود که تضاد منافع را ایجاد می‌کند.

• ما در مرکز افتا، استفاده از مشاوره آزمایشگاه را برای تهیه اسناد اصلاً پیشنهاد نمی‌کنیم؛ به جای آن توصیه می‌کنیم آزمایشگاه‌ها دوره توسعه امن نرم‌افزار را برگزار کنند. رویکرد درست این است که شرکت‌ها به بلوغ لازم برای تکمیل اسناد برسند.
• آموزش فرآیند و شرح کلیات روند ارزیابی، توسط مرکز افتا انجام می‌شود و برای نحوه تکمیل مستندات هم در حال صدور مجوز آموزش برای آزمایشگاه هستیم. در کل هم باید به سمت توسعه امن نرم‌افزار حرکت کنیم و می‌توانیم با کمک معاونت علمی و فناوری ریاست جمهوری، و سازمان نظام صنفی رایانه‌ای توسعه آموزش و بلوغ شرکت‌ها در حوزه امنیت نرم‌افزار را افزایش دهیم.

چرا محصولاتی که درصدی از از مسیر ارزیابی امنیتی را با موفقیت طی کرده‌اند، گواهی نسبی دریافت نمی‌کنند؟

• ارزیابی مرکز افتا، یک ارزیابی امنیتی است. اگر این ارزیابی در مورد کیفیت و کارایی بود امکان سطح‌بندی بیشتری وجود داشت. ولی چون مأموریت افتا ارزیابی امنیتی است، تنها دو نقطه امن و ناامن وجود دارد و میانه این طیف نمی‌توان نقطه‌ای برای امنیت تعریف کرد. البته در این موضوع هم می‌توانیم با همکاری کمیسیون‏های سازمان نظام صنفی رایانه‏ای پیشنهادهایی را جمع‌آوری و ارائه کنیم.

موضوع مستقل شدن صدور گواهی افتا از تمدید اعتبار آزمایشگاه‌ها و تسریع فرآیند تمدید اعتبار آن‏ها، از دیگر موارد مطرح شده از سوی آزمایشگاه‌ها، در این نشست بودند.

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

همچنین عسکرزاده در خصوص هزینه‌های اخذ گواهی افتا، اعلام داشت که اخذ گواهی افتا برای محصولاتی که به صورت منحصر به فرد برای دستگاه و یا نهادی طراحی و تولید می‌شوند، منطقاً به عهده همان دستگاه و نهاد استفاده‌کننده است. او تأکید کرد که بخش خصوصی باید در عقد قرارداد به این موضوع دقت کنند که مسئولیت اخذ گواهی و هزینه‌های آن بر عهده کدام طرف قرارداد است. زیرا در نهایت گواهی به نام دستگاه استفاده‌کننده محصول صادر می‌شود.

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

منبع : سازمان نظام صنفی رایانه ای تهران