آنتیویروس بومی چیست؟ بررسی مزایا، قابلیتها و امنیت آنتیویروسهای ایرانی
آشنایی با آنتیویروسهای بومی، سابقه تولید آنها در ایران، قابلیتها و مزایای محصولات داخلی و چالشهای پیش روی توسعه و ارزیابی امنیتی آنها.
در سالهای اخیر تعدادی آنتیویروس بومی معرفی و وارد بازار شدهاند؛ محصولاتی که هدف اصلی آنها کاهش وابستگی به راهکارهای خارجی و پاسخ به نیازهای امنیتی زیرساختهای کشور عنوان شده است.
در روزهای اخیر نیز محصولی به نام «آیزا» بهعنوان دومین آنتیویروس ملی رونمایی شد. بر اساس اطلاعات منتشرشده در برخی رسانهها، موتور تشخیص این محصول با تکیه بر توان مهندسی داخلی و فناوریهای سطح هسته ویندوز توسعه یافته است. در معماری آن نیز از یادگیری ماشین استفاده شده است. سازندگان آیزا همچنین از ایجاد اکوسیستمی متشکل از آنتیویروس، EDR و XDR در کنار سامانه مدیریت دسترسیهای ویژه و سامانه جلوگیری از نشت اطلاعات سخن گفتهاند. نسخه فعلی برای ویندوز توسعه یافته و نسخه لینوکس نیز برای نیمه دوم سال جاری وعده داده شده است.
پیش از این نیز نامهای دیگری برای آنتیویروس ملی مطرح شدهاند. ایمن، پادویش و آنتیویروس دانشگاه شیراز از جمله موارد مرتبط با این عنوان هستند. بر اساس ادعای شرکت مهران رایانه، در سال ۱۳۷۳ نخستین آنتیویروس کاملاً ایرانی با نام تجاری «ایمن» تولید و وارد بازار شده است. پادویش نیز از دیگر آنتیویروسهای بومی است که گفته میشود نخستین نمونه در کشور بوده است. با این حال، مرکز آپای دانشگاه شیراز در سال ۱۳۹۱ مدعی شد که نخستین ضدویروس بومی را تولید کرده است.
یکی از ویژگیهای اعلامشده درباره آنتیویروسی که بهتازگی به بازار عرضه شده، امکان بهروزرسانی آفلاین و انتقال داده از طریق شبکه ملی اطلاعات است؛ قابلیتی که در شرایط محدودیت یا اختلال در دسترسی به اینترنت جهانی میتواند یک مزیت عملیاتی محسوب شود. از سوی دیگر، این معماری چند پرسش مهم امنیتی را مطرح میکند: بستههای بهروزرسانی چگونه اعتبارسنجی میشوند؟ چه سازوکاری از دستکاری آنها جلوگیری میکند؟ و اگر زیرساخت توزیع بهروزرسانی یا یکی از اجزای زنجیره تولید نرمافزار مورد نفوذ قرار گیرد، چه لایهای میتواند از ورود کد مخرب به سیستمهای کاربران جلوگیری کند؟
موضوع زمانی اهمیت بیشتری پیدا میکند که بدانیم آنتیویروسها، برخلاف بسیاری از نرمافزارهای معمولی، برای انجام وظایف خود معمولاً به سطح بالایی از دسترسی در سیستم نیاز دارند. مؤسسه ملی استاندارد و فناوری آمریکا (NIST) نرمافزارهای امنیتی Endpoint را در زمره نرمافزارهایی قرار میدهد که معمولاً با دسترسیهای بالا نصب میشوند و میتوانند اطلاعات دقیقی از وضعیت سیستمعامل، برنامهها، حسابهای کاربری و محیط اجرایی جمعآوری کنند.
بنابراین، آنتیویروس نهتنها یک ابزار دفاعی است، بلکه خود نیز باید بهعنوان یک جزء حساس با سطح حمله قابلتوجه ارزیابی شود.
خود آنتیویروس میتواند هدف حمله باشد
یکی از مهمترین ریسکهای محصولات امنیتی این است که مهاجم بهجای عبور از آنها، خود ابزار دفاعی را هدف قرار دهد. بر اساس MITRE ATT&CK، که یک چارچوب و دانشنامه تخصصی در حوزه امنیت سایبری است، تکنیکی مشخص با عنوان Exploitation for Defense Impairment در سال ۲۰۲۶ معرفی شده است. بر اساس این تکنیک، مهاجمان میتوانند از آسیبپذیریهای موجود در نرمافزارهای امنیتی مانند آنتیویروس و EDR برای تضعیف یا غیرفعالکردن سازوکارهای دفاعی استفاده کنند. در صورت موفقیت، مهاجم میتواند فرایندهای امنیتی را متوقف کند، حفاظت را دور بزند یا قابلیت تشخیص و واکنش سیستم را کاهش دهد.
این چارچوب همچنین در تکنیک Disable or Modify Tools توضیح میدهد که مهاجمان ممکن است سرویسها و فرایندهای آنتیویروس را متوقف کنند، تنظیمات آن را تغییر دهند، فایلهای پیکربندی یا Registry را دستکاری کنند یا حتی مانع بهروزرسانی نرمافزار امنیتی شوند.
در مورد آیزا، این موضوع یک پرسش مهم را مطرح میکند: اگر مهاجم موفق شود بخشی از خود آیزا یا سرویسها و درایورهای آن را مختل کند، آیا یک سامانه مستقل میتواند این اختلال را تشخیص دهد؟
وجود EDR و XDR در معماری اعلامشده آیزا میتواند در چنین سناریویی اهمیت داشته باشد؛ زیرا دفاع چندلایه میتواند مانع وابستگی کامل سازمان به یک ابزار شود. با این حال، میزان واقعی این استقلال به نحوه پیادهسازی و جداسازی اجزای این اکوسیستم بستگی دارد.
Kernel؛ مزیت آیزا و همزمان نقطه حساس آن
یکی از ویژگیهایی که سازندگان آیزا بر آن تأکید کردهاند، استفاده از فناوریهای سطح Kernel ویندوز برای افزایش دقت تشخیص و چابکی محصول است. دسترسی در این سطح میتواند به آنتیویروس امکان مشاهده و کنترل عمیقتری بر فعالیتهای سیستم بدهد؛ اما همین دسترسی، پیامد احتمالی آسیبپذیری را نیز افزایش میدهد.
یک نمونه مشهور، بررسی Google Project Zero درباره محصولات Symantec و Norton در سال ۲۰۱۶ است. پژوهشگران چندین آسیبپذیری بحرانی را در موتور این محصولات پیدا کردند. در برخی موارد، کد آسیبپذیر در Kernel ویندوز اجرا میشد و امکان فساد حافظه Kernel وجود داشت. Project Zero هشدار داد که اجرای برخی اجزای پیچیده موتور آنتیویروس در Kernel میتواند سطح حمله قابلتوجهی ایجاد کند.
هرچند این تجربه به معنای آسیبپذیر بودن آیزا نیست، اما یک اصل مهم را نشان میدهد: هرچه آنتیویروس به لایههای عمیقتری از سیستم دسترسی داشته باشد، امنیت درایورها، کدهای Kernel و موتور پردازش آن اهمیت بیشتری پیدا میکند.
در این شرایط، پرسشهایی درباره امنیت Driverهای آیزا نیز مطرح میشود: آیا این درایورها بهطور مستقل ممیزی و تست نفوذ شدهاند؟ آیا برای آنها فرایند مشخصی برای کشف و اصلاح آسیبپذیری وجود دارد؟ و در صورت کشف یک نقص بحرانی، سازوکار انتشار وصله و واکنش اضطراری چگونه خواهد بود؟
بهروزرسانی آفلاین میتواند به نقطه حساس تبدیل شود
بهروزرسانی آفلاین آیزا یکی از ویژگیهایی است که میتواند برای سازمانهایی که دسترسی دائمی به اینترنت جهانی ندارند، مزیت محسوب شود. اما آفلاین بودن بهخودیخود به معنای امن بودن بهروزرسانی نیست. امنیت این معماری تا حد زیادی به زنجیره اعتماد بهروزرسانی وابسته است؛ یعنی اینکه بسته بهروزرسانی کجا تولید میشود، چه کسی آن را امضا میکند، چگونه به مقصد منتقل میشود و سیستم مقصد چگونه اصالت و یکپارچگی آن را بررسی میکند.
اتفاقی که در ژانویه ۲۰۲۶ برای آنتیویروس eScan رخ داد، اهمیت این موضوع را بهخوبی نشان میدهد. شرکت امنیتی Morphisec گزارش کرد که مهاجمان زیرساخت قانونی بهروزرسانی eScan را مورد سوءاستفاده قرار دادند و بهروزرسانی مخرب را از همان کانال مورد اعتماد به سیستمهای کاربران رساندند. این حمله کاربران سازمانی و عادی را در نقاط مختلف جهان تحت تأثیر قرار داد و حتی تنظیمات و فایلهای مرتبط با بهروزرسانی آنتیویروس را دستکاری کرد تا امکان بهروزرسانی و اصلاح خودکار مختل شود.
کسپرسکی نیز در بررسی فنی این حمله، آن را یک Supply-chain attack علیه خود نرمافزار آنتیویروس توصیف کرد. در نتیجه، درباره سازوکار بهروزرسانی آفلاین آیزا این پرسشها مطرح میشود: آیا هر بسته بهروزرسانی آیزا بهصورت رمزنگاریشده و قابل راستیآزمایی امضا میشود؟ آیا سیستم مقصد امضای دیجیتال و تمامیت بسته را بررسی میکند؟ آیا امکان بازگرداندن سیستم به وضعیت قبل وجود دارد؟ و در صورت نفوذ یا دستکاری مخزن یا سرور بهروزرسانی، چه سازوکاری برای توقف توزیع بسته آلوده وجود دارد؟
پاسخ به این پرسشها زمانی اهمیت بیشتری پیدا میکند که آیزا در تعداد زیادی از زیرساختهای حساس کشور مستقر شود.
ادعای تشخیص بدافزارهای ناشناخته باید مستقل سنجیده شود
یکی دیگر از ویژگیهای اعلامشده برای آیزا، استفاده از هوش مصنوعی و یادگیری ماشین برای شناسایی بدافزارهای ناشناخته و تهدیدهای جدید است. اما در محصولات امنیتی، «استفاده از AI/ML» بهتنهایی معادل «تشخیص بهتر» نیست. آنچه اهمیت دارد، نتیجه آزمونهای مستقل و قابلتکرار است.
برای ارزیابی چنین محصولی باید مشخص باشد نرخ تشخیص تهدیدهای روز صفر چقدر است، نرخ False Positive و False Negative چه میزان است و مدل تشخیص در برابر روشهای مختلف دور زدن چگونه عمل میکند.
بنابراین، ادعای استفاده از هوش مصنوعی باید با دادههای آزمایشگاهی و آزمونهای مستقل همراه باشد؛ همانطور که محصولات شناختهشده امنیتی در آزمایشگاههای مستقل و بر اساس معیارهای مشخص مورد ارزیابی قرار میگیرند.
زنجیره تأمین نرمافزار فقط به بهروزرسانی محدود نمیشود
ریسک زنجیره تأمین صرفاً به سرور بهروزرسانی محدود نمیشود. کتابخانههای متنباز، اجزای شخص ثالث، ابزارهای ساخت و تولید نرمافزار و درایورها نیز بخشی از این زنجیره هستند.
نمونه Symantec که Google Project Zero بررسی کرد، نشان داد حتی استفاده از کدهای قدیمی شخص ثالث میتواند به ایجاد آسیبپذیری در محصول نهایی منجر شود. Project Zero در همان بررسی اشاره کرد که برخی کتابخانههای مورد استفاده در موتور Symantec بهموقع بهروزرسانی نشده بودند و آسیبپذیریهای عمومی آنها به محصول امنیتی نیز راه پیدا کرده بود.
بنابراین، درباره یک آنتیویروس بومی مانند آیزا نیز باید مشخص باشد چه میزان از کد محصول کاملاً داخلی است و چه بخشهایی از کتابخانهها یا اجزای شخص ثالث تشکیل شدهاند و برای مدیریت آسیبپذیری این اجزا چه سازوکاری وجود دارد.
هرچه آنتیویروس فراگیرتر شود، پیامد نقص آن بزرگتر میشود
یک آنتیویروس که روی چند سیستم محدود نصب شده است، در صورت بروز مشکل دامنه اثر محدودی دارد. اما اگر همان محصول بهعنوان راهکار امنیتی مشترک در تعداد زیادی از سازمانها، بانکها و زیرساختهای حیاتی نصب شود، یک آسیبپذیری یا خطای جدی میتواند اثر بسیار گستردهتری ایجاد کند. در اینجا مسئله فقط «آسیبپذیری» نیست؛ ریسک تمرکز نیز مطرح است.
اگر بخش بزرگی از زیرساختهای کشور از یک موتور، یک محصول، یک زنجیره بهروزرسانی یا یک اکوسیستم امنیتی مشترک استفاده کنند، اختلال، نفوذ یا دستکاری آن میتواند همزمان تعداد زیادی از نقاط پایانی را تحت تأثیر قرار دهد. به همین دلیل، استفاده گسترده از آیزا باید همراه با معماری دفاعی چندلایه باشد؛ بهگونهای که شکست یا اختلال یک محصول به معنای از بین رفتن تمام قابلیتهای دفاعی سازمان نباشد.
بومی بودن جایگزین ارزیابی مستقل نیست
بومی بودن آیزا میتواند از منظر تابآوری و کاهش وابستگی به محصولات خارجی یک مزیت باشد؛ بهخصوص برای سازمانهایی که به دلیل محدودیت دسترسی به اینترنت جهانی یا تحریمها با چالش دریافت بهروزرسانی و خدمات پشتیبانی خارجی مواجهاند. اما «بومی بودن» بهتنهایی یک معیار امنیتی نیست.
برای ارزیابی امنیت یک محصول امنیتی، باید مشخص باشد که کد و درایورهای آن چگونه توسعه داده شدهاند، چه تستهای امنیتی مستقلی روی آنها انجام شده است، فرایند کشف و افشای آسیبپذیری چیست، بهروزرسانیها چگونه امضا و اعتبارسنجی میشوند و در صورت کشف یک آسیبپذیری بحرانی، چه مدت زمانی برای اصلاح آن در نظر گرفته شده است.
آیزا برای اثبات امنیت خود به چه چیزهایی نیاز دارد؟
در مجموع، با توجه به اینکه آنتیویروس آیزا فعلاً در مرحله معرفی قرار دارد و در منابع عمومی گزارشی از یک آسیبپذیری مشخص در خود این محصول منتشر نشده است، نمیتوان بر اساس ریسکهای عمومی آنتیویروسها نتیجه گرفت که آیزا ناامن است. با این حال، اگر قرار باشد این محصول در زیرساختهای حساس و حیاتی کشور بهصورت گسترده مورد استفاده قرار گیرد، انتشار شواهد مستقل درباره امنیت آن اهمیت ویژهای پیدا میکند.
از جمله مهمترین مواردی که میتوان درباره آیزا مطالبه کرد، این موارد است:
- نتایج آزمونهای مستقل تشخیص بدافزار و Zero-day؛
- نرخ False Positive و False Negative؛
- نتایج تست نفوذ مستقل روی موتور و درایورهای Kernel؛
- سازوکار Secure Update و امضای دیجیتال بستههای آفلاین؛
- امکان نفوذ یا دسترسی غیرمجاز در صورت انتشار بهروزرسانی معیوب یا آلوده؛
- فرایند مدیریت آسیبپذیری و اعلام CVE؛
- سازوکار افشای مسئولانه آسیبپذیریها و تیم واکنش به رخدادهای امنیتی؛
- فهرست یا SBOM اجزای شخص ثالث مورد استفاده؛
- نحوه آزمون مدلهای AI/ML در برابر روشهای Evasion؛
- و مهمتر از همه، معماری دفاعی مستقل در صورت ازکارافتادن یا دستکاری خود آنتیویروس.
آیزا میتواند پاسخی به یک نیاز واقعی باشد: داشتن یک راهکار امنیتی که برای دریافت بهروزرسانی و عملکرد روزمره، وابستگی دائمی به اینترنت جهانی و ارائهدهندگان خارجی نداشته باشد. از این منظر، معماری بومی و امکان بهروزرسانی آفلاین میتواند به تابآوری سایبری کمک کند. اما همین ویژگیها پرسشهای جدیدی نیز ایجاد میکنند.
آنتیویروسی که قرار است از سیستمها در برابر حمله محافظت کند، خود باید در برابر حمله مقاوم باشد. موتوری که در سطح Kernel فعالیت میکند باید از امنیت درایورها و کدهای خود اطمینان داشته باشد و کانال بهروزرسانی که قرار است تهدیدها را از سیستم دور نگه دارد، نباید به مسیری برای ورود تهدید تبدیل شود.
