تحلیل فنی دفاعی و منبع‌محور: Eclipse Foundation Eclipse Milo

مفاهیم و زمینه‌های فنی

Eclipse Milo یک پیاده‌سازی متن‌باز از پروتکل OPC UA (معماری یکپارچه ارتباطات پلتفرم‌محور) است که برای برقراری ارتباط امن و استاندارد میان تجهیزات صنعتی و سیستم‌های نظارتی به‌کار می‌رود. این پروتکل به‌عنوان ستون فقرات تبادل داده در زیرساخت‌های حیاتی مانند صنایع شیمیایی، تولید، انرژی و آب و فاضلاب عمل می‌کند. بر اساس advisory منتشرشده توسط CISA با شناسه ICSA-26-288-01، پنج آسیب‌پذیری در نسخه‌های مختلف این کتابخانه شناسایی شده است که می‌توانند پیامدهای جدی برای امنیت این زیرساخت‌ها داشته باشند.

این advisory به‌طور مشخص به پنج نقص امنیتی اشاره دارد که شامل مجوزدهی نادرست، عدم آزادسازی حافظه پس از عمر مفید، عدم وجود مجوز، ناهماهنگی در پاسخ‌های مشاهده‌پذیر و عدم آزادسازی منابع پس از عمر مفید می‌شود. دامنه تأثیر این آسیب‌پذیری‌ها نسخه‌های 0.6.0 تا 1.1.4 از Eclipse Milo را در بر می‌گیرد. نکته حائز اهمیت آن است که بهره‌برداری موفق از این نقص‌ها می‌تواند به مهاجم اجازه دهد داده‌های محافظت‌شده را حذف کند، اعتبارنامه‌های کاربری را بازیابی کرده و هویت کاربران قانونی را جعل نماید، یا باعث توقف پاسخ‌گویی سرور به تمام کلاینت‌ها شود.

بخش قابل توجهی از این آسیب‌پذیری‌ها به مکانیزم‌های احراز هویت و کنترل دسترسی مرتبط هستند. برای مثال، در یکی از موارد، سرویس Call پس از محاسبه مجوز، دسته اصلی مخلوط را به هندلرهای فضای آدرس ارسال می‌کند که این امر به یک کلاینت ناشناس یا کم‌امتیاز اجازه می‌دهد با ترکیب یک متد مجاز با یک متد غیرمجاز، از محدودیت‌های امنیتی عبور کند. در مورد دیگر، تابع OpcUaServerConfig.copy() نمی‌تواند RoleMapper پیکربندی‌شده را حفظ کند که این نقص می‌تواند منجر به نادیده گرفته شدن بررسی‌های مجوز مبتنی بر نقش شود.

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

• پروتکل OPC UA به‌عنوان استاندارد ارتباطی در زیرساخت‌های حیاتی (شیمیایی، تولید، انرژی، آب و فاضلاب) در سطح جهانی مستقر است.
• آسیب‌پذیری‌های شناسایی‌شده شامل CWE-863 (مجوزدهی نادرست)، CWE-401 (عدم آزادسازی حافظه)، CWE-862 (عدم وجود مجوز) و موارد مرتبط با ناهماهنگی پاسخ هستند.
• نسخه‌های آسیب‌پذیر شامل Eclipse Milo از 0.6.0 تا 1.1.4 می‌شوند و نسخه 1.1.5 به‌عنوان نسخه اصلاحی توسط توسعه‌دهنده معرفی شده است.
• بهره‌برداری از این نقص‌ها می‌تواند منجر به حذف داده‌های محافظت‌شده، بازیابی اعتبارنامه‌ها، جعل هویت کاربران و یا توقف کامل سرویس‌دهی سرور شود.

شواهد و تله‌متری

بر اساس advisory منتشرشده توسط CISA با شناسه ICSA-26-288-01، شش آسیب‌پذیری در کتابخانه متن‌باز Eclipse Milo شناسایی شده است که به‌عنوان پیاده‌سازی OPC UA مورد استفاده قرار می‌گیرد. این advisory در تاریخ ۱۵ اکتبر ۲۰۲۶ منتشر شده و نسخه‌های آسیب‌پذیر را در دو بازه مجزا مشخص می‌کند: نسخه‌های 0.6.0 تا 1.1.4 برای چهار CVE و نسخه‌های 1.0.0 تا 1.1.4 برای سه CVE دیگر. نکته حائز اهمیت آن است که برخی CVEها در هر دو بازه قرار می‌گیرند و مجموعاً شش CVE منحصربه‌فرد در این advisory پوشش داده شده است.

از منظر تله‌متری، معیارهای CVSS برای هر آسیب‌پذیری به‌صورت جداگانه ارائه شده است. برای مثال، CVE-2026-62927 با نمره پایه 7.5 (HIGH) در CVSS v3.1 و 8.7 (HIGH) در CVSS v4.0 ارزیابی شده است. این آسیب‌پذیری از نوع «مجوزدهی نادرست» (CWE-863) بوده و بردار حمله آن شبکه‌ای، با پیچیدگی پایین و بدون نیاز به احراز هویت است. به‌طور مشابه، CVE-2026-63252 که به «عدم آزادسازی حافظه پس از عمر مفید» (CWE-401) مربوط می‌شود، نمره 7.5 در v3.1 و 8.7 در v4.0 دارد. سایر CVEها نیز نمرات متفاوتی دارند که در ادامه به تفکیک ارائه می‌شود.

لازم به ذکر است که تمامی این آسیب‌پذیری‌ها توسط CISA به‌عنوان «شناخته‌شده» (known_affected) علامت‌گذاری شده‌اند و هیچ‌یک از آن‌ها در کاتالوگ KEV (آسیب‌پذیری‌های مورد بهره‌برداری فعال) قرار ندارند. با این حال، ماهیت برخی از این آسیب‌پذیری‌ها، مانند امکان حذف داده‌های محافظت‌شده یا بازیابی اعتبارنامه‌ها، آن‌ها را در معرض بهره‌برداری جدی قرار می‌دهد. در ادامه، جزئیات هر CVE به‌صورت منبع‌محور و بدون تفسیر اضافی ارائه می‌شود.

• CVE-2026-62927: نمره 7.5 (v3.1) و 8.7 (v4.0)؛ CWE-863 (مجوزدهی نادرست)؛ نسخه‌های 1.0.0 تا 1.1.4؛ حمله از طریق سرویس Call با ترکیب روش‌های مجاز و غیرمجاز.
• CVE-2026-63252: نمره 7.5 (v3.1) و 8.7 (v4.0)؛ CWE-401 (عدم آزادسازی حافظه)؛ نسخه‌های 0.6.0 تا 1.1.4؛ حمله از طریق ارسال تکه‌های ناقص پیام و قطع اتصال.
• CVE-2026-58080: نمره 8.2 (v3.1) و 8.8 (v4.0)؛ CWE-862 (عدم مجوزدهی)؛ نسخه‌های 1.0.0 تا 1.1.4؛ مشکل در متد copy() پیکربندی سرور که منجر به نادیده‌گرفتن نقش‌ها می‌شود.
• CVE-2026-63248: نمره 7.5 (v3.1) و 8.7 (v4.0)؛ CWE-862 (عدم مجوزدهی)؛ نسخه‌های 0.6.0 تا 1.1.4؛ دسترسی به گره‌های تشخیصی بدون کنترل دسترسی.
• CVE-2026-60007: نمره 7.5 (v3.1) و 8.7 (v4.0)؛ CWE-306 (عدم احراز هویت)؛ نسخه‌های 0.6.0 تا 1.1.4؛ امکان حذف داده‌های محافظت‌شده.
• CVE-2026-61387: نمره 7.5 (v3.1) و 8.7 (v4.0)؛ CWE-400 (عدم آزادسازی منابع)؛ نسخه‌های 1.0.0 تا 1.1.4؛ حملات انکار سرویس از طریق مصرف منابع.

روند کار و تحلیل

برای ارزیابی آسیب‌پذیری‌های اعلام‌شده در Eclipse Milo، نخست باید فهرست دقیقی از نسخه‌های نصب‌شده در محیط‌های صنعتی تهیه شود. با توجه به توصیه CISA، ارتقا به نسخه 1.1.5 یا بالاتر برای تمامی نمونه‌های آسیب‌پذیر ضروری است. در محیط‌هایی که از نسخه‌های 0.6.x استفاده می‌شود، هیچ به‌روزرسانی برای این شاخه منتشر نشده و مهاجرت به نسخه 1.1.5 یا جدیدتر تنها گزینه پیشنهادی است. این اقدام باید با هماهنگی واحدهای بهره‌برداری و با در نظر گرفتن پنجره‌های نگهداری برنامه‌ریزی شود.

پس از شناسایی نسخه‌ها، باید پیکربندی‌های مرتبط با کنترل دسترسی و احراز هویت بررسی شود. آسیب‌پذیری‌هایی مانند CVE-2026-62927 و CVE-2026-58080 نشان می‌دهند که در صورت فعال بودن سرویس Call یا استفاده از متد copy() در پیکربندی، ممکن است سطوح دسترسی نادیده گرفته شوند. بنابراین، ممیزی پیکربندی سرورهای OPC UA برای اطمینان از اعمال صحیح RoleMapper و سیاست‌های مجوزدهی ضروری است. همچنین باید از غیرفعال بودن endpointهای None/None در محیط‌های حساس اطمینان حاصل شود، زیرا این امر می‌تواند به دسترسی ناشناس منجر شود.

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

• شناسایی تمامی نسخه‌های Eclipse Milo در محیط و مقایسه با محدوده‌های آسیب‌پذیر اعلام‌شده (>=0.6.0 تا <=1.1.4 و >=1.0.0 تا <=1.1.4).
• بررسی پیکربندی‌های سرور برای اطمینان از فعال بودن کنترل‌های دسترسی مبتنی بر نقش و غیرفعال بودن سرویس‌های غیرضروری.
• ارتقا به نسخه 1.1.5 یا بالاتر برای تمامی سیستم‌های آسیب‌پذیر، با اولویت‌بندی بر اساس اهمیت بحرانی زیرساخت.
• مستندسازی تمامی اقدامات اصلاحی و به‌روزرسانی‌ها در سامانه مدیریت پیکربندی.

1. تهیه فهرست جامع از تمامی سرورهای OPC UA مبتنی بر Eclipse Milo و ثبت نسخه دقیق آن‌ها.
2. مقایسه نسخه‌های شناسایی‌شده با محدوده‌های آسیب‌پذیر مندرج در advisory و علامت‌گذاری موارد در معرض خطر.
3. انجام ممیزی پیکربندی برای بررسی فعال بودن RoleMapper و تنظیمات مجوزدهی در فایل‌های پیکربندی.
4. هماهنگی با تیم بهره‌برداری برای برنامه‌ریزی ارتقا به نسخه 1.1.5 در پنجره‌های نگهداری مجاز.
5. پس از ارتقا، انجام آزمون‌های عملکردی و امنیتی برای اطمینان از اعمال صحیح اصلاحات.

اولویت‌بندی و غربالگری

در ارزیابی آسیب‌پذیری‌های اعلام‌شده برای Eclipse Milo، نخستین گام، تعیین سلسله‌مراتب رسیدگی بر پایه معیارهای فنی مستند است. بر اساس داده‌های منتشرشده در advisory رسمی CISA، پنج آسیب‌پذیری با شناسه‌های CVE-2026-63252، CVE-2026-63248، CVE-2026-60007، CVE-2026-62927، CVE-2026-58080 و CVE-2026-61387 شناسایی شده‌اند. معیار اولویت‌بندی، ترکیبی از نمره پایه CVSS، نوع بردار دسترسی (شبکه‌ای یا محلی)، پیش‌شرط‌های احراز هویت، و تأثیر بر سه ضلع محرمانگی، یکپارچگی و در دسترس بودن است. برای نمونه، آسیب‌پذیری CVE-2026-58080 با نمره 8.2 در CVSS v3.1 به دلیل نیاز نداشتن به احراز هویت و امکان دستکاری یکپارچگی داده‌ها، در رده بحرانی‌تر نسبت به موارد صرفاً منجر به قطع سرویس قرار می‌گیرد.

در غربالگری اولیه، باید میان آسیب‌پذیری‌های قابل بهره‌برداری از راه دور بدون احراز هویت (مانند CVE-2026-63252 که به حافظه مستقیم وابسته است) و مواردی که نیازمند پیکربندی خاص یا دسترسی از پیش فراهم‌شده هستند، تمایز قائل شد. تمامی موارد اعلام‌شده دارای بردار شبکه‌ای (AV:N) و پیچیدگی حمله پایین (AC:L) هستند که این امر ریسک بهره‌برداری را افزایش می‌دهد. با این حال، تأثیر نهایی باید بر اساس معماری شبکه صنعتی و وجود لایه‌های دفاعی محیطی سنجیده شود. به عنوان یک توصیه مستند، اولویت رسیدگی باید ابتدا به مواردی داده شود که هر دو معیار «بدون احراز هویت» و «تأثیر یکپارچگی بالا» را دارند، سپس موارد منجر به افشای اطلاعات، و در نهایت موارد انکار سرویس.

توصیه می‌شود تیم‌های دفاعی، پیش از هر اقدامی، فهرست دارایی‌های مبتنی بر Milo را با نسخه‌های دقیق استخراج کنند و آن را با محدوده نسخه‌های آسیب‌پذیر (0.6.0 تا 1.1.4) تطبیق دهند. این غربالگری باید به صورت خودکار و با استفاده از ابزارهای مدیریت پیکربندی انجام شود تا از خطای انسانی جلوگیری گردد. لازم به ذکر است که ارتقا به نسخه 1.1.5 به عنوان راه‌حل رسمی فروشنده اعلام شده است؛ اما برای نسخه‌های 0.6.x، هیچ وصله‌ای منتشر نشده و مهاجرت به نسخه جدیدتر اجتناب‌ناپذیر است. این یک توصیه مبتنی بر شواهد است و پیش از اعمال آن، باید تست سازگاری در محیط آزمایشگاهی انجام شود.

• اولویت یکم: آسیب‌پذیری‌های با نمره CVSS بالاتر از 8.0 و بدون نیاز به احراز هویت (CVE-2026-58080)
• اولویت دوم: موارد منجر به افشای اطلاعات حساس مانند اعتبارنامه‌ها (CVE-2026-63248)
• اولویت سوم: آسیب‌پذیری‌های انکار سرویس که نیازمند تعامل مکرر هستند (CVE-2026-63252)
• غربالگری بر اساس نسخه دقیق محصول، نه صرفاً وجود در محدوده کلی

1. استخراج فهرست کامل دارایی‌های Milo و ثبت نسخه دقیق هر نمونه
2. تطبیق نسخه‌ها با محدوده آسیب‌پذیری اعلام‌شده در advisory
3. محاسبه نمره ریسک ترکیبی بر اساس CVSS و اهمیت عملکردی هر سرور OPC UA
4. مستندسازی یافته‌ها در یک جدول اولویت‌بندی برای تصمیم‌گیری مدیریتی

مثبت‌های کاذب و چالش‌ها

در ارزیابی امنیتی کتابخانه Eclipse Milo، یکی از مهم‌ترین چالش‌ها، تشخیص دقیق وضعیت آسیب‌پذیری در نسخه‌های قدیمی‌تر است. بر اساس اطلاعات منتشرشده توسط CISA در advisory شماره ICSA-26-288-01، نسخه‌های 0.6.x این کتابخانه با وجود اینکه در محدوده نسخه‌های آسیب‌پذیر (از 0.6.0 تا 1.1.4) قرار دارند، هیچ وصله‌ای برای رفع آسیب‌پذیری‌های شناسایی‌شده دریافت نکرده‌اند. این وضعیت می‌تواند منجر به ایجاد مثبت کاذب در فرآیندهای اسکن آسیب‌پذیری شود، به این معنا که یک سیستم اسکن ممکن است نسخه 0.6.x را به‌عنوان نسخه‌ای که وصله شده است شناسایی کند، در حالی که در واقعیت هیچ به‌روزرسانی امنیتی برای آن منتشر نشده است.

چالش اصلی در این سناریو، تمایز بین نسخه‌های وصله‌شده و وصله‌نشده است. برای نسخه‌های 1.0.0 تا 1.1.4، ارتقا به نسخه 1.1.5 به‌عنوان راه‌حل رسمی توسط Eclipse Foundation توصیه شده است. اما برای کاربرانی که از نسخه‌های 0.6.x استفاده می‌کنند، تنها گزینه موجود، مهاجرت کامل به نسخه 1.1.5 یا بالاتر است. این مهاجرت ممکن است به‌دلیل تغییرات API یا تفاوت‌های رفتاری بین نسخه‌های اصلی، ساده نباشد و نیازمند برنامه‌ریزی دقیق و آزمون‌های سازگاری باشد. در نتیجه، ابزارهای ارزیابی خودکار ممکن است به‌اشتباه وجود نسخه 0.6.x را به‌عنوان یک وضعیت امن قابل قبول گزارش دهند، در حالی که این نسخه‌ها عملاً در معرض خطر هستند.

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

• نسخه‌های 0.6.x هیچ وصله امنیتی دریافت نکرده‌اند و مهاجرت به 1.1.5 یا بالاتر تنها راه‌حل است.
• ابزارهای اسکن خودکار ممکن است نسخه‌های 0.6.x را به‌عنوان نسخه‌های امن گزارش دهند، زیرا محدوده نسخه‌های آسیب‌پذیر را به‌درستی تفسیر نمی‌کنند.
• برای جلوگیری از مثبت کاذب، لازم است فرآیند ارزیابی شامل بررسی دستی و تطبیق دقیق نسخه نصب‌شده با محدوده‌های اعلام‌شده در advisory باشد.

1. مستندسازی تمام نسخه‌های Eclipse Milo نصب‌شده در زیرساخت سازمان و تعیین اینکه آیا در محدوده آسیب‌پذیر (0.6.0 تا 1.1.4) قرار دارند یا خیر.
2. برای سیستم‌هایی که از نسخه 0.6.x استفاده می‌کنند، برنامه‌ریزی مهاجرت به نسخه 1.1.5 یا بالاتر را آغاز کنید و پیش از اجرا، آزمون‌های سازگاری کامل انجام دهید.
3. پس از ارتقا، صحت پیکربندی‌های امنیتی مانند RoleMapper و تنظیمات دسترسی را مجدداً بررسی کنید تا از عدم وجود مشکلات ناشی از تغییرات نسخه اطمینان حاصل شود.

محدودیت‌ها و شکاف‌های اطلاعاتی

در advisory منتشرشده توسط CISA با شناسه ICSA-26-288-01، اطلاعات فنی برای پنج آسیب‌پذیری مرتبط با Eclipse Milo ارائه شده است. با این حال، برای دو مورد از این آسیب‌پذیری‌ها یعنی CVE-2026-60007 و CVE-2026-61387، جزئیات کامل در متن موجود نیست. این بدان معناست که نوع دقیق نقص، بردار حمله، و تأثیر بالقوه این دو مورد به‌طور شفاف مستند نشده است. به‌عنوان مثال، در حالی که برای CVE-2026-62927 توضیح داده شده که مشکل در توزیع دسته‌ای درخواست‌ها پس از احراز هویت است، برای CVE-2026-60007 هیچ شرحی ارائه نشده و تنها به محدوده نسخه‌های آسیب‌پذیر اشاره شده است.

شکاف اطلاعاتی دیگر، عدم پوشش نسخه‌های قدیمی‌تر از 0.6.0 است. advisory به‌صراحت اعلام می‌کند که برای کاربران نسخه 0.6.x هیچ به‌روزرسانی امنیتی منتشر نشده و آن‌ها باید به نسخه 1.1.5 یا بالاتر مهاجرت کنند. این موضوع برای سازمان‌هایی که هنوز از نسخه‌های قدیمی‌تر استفاده می‌کنند، یک چالش جدی محسوب می‌شود، زیرا هیچ مسیر ارتقای امنیتی برای آن‌ها تعریف نشده است. همچنین، برای برخی از آسیب‌پذیری‌ها مانند CVE-2026-63248، اطلاعات مربوط به نسخه‌های آسیب‌پذیر به‌صورت ناقص ارائه شده و بخشی از متن در دسترس نیست.

علاوه بر این، در advisory اشاره شده که بهره‌برداری موفق از این آسیب‌پذیری‌ها می‌تواند منجر به حذف داده‌های محافظت‌شده، بازیابی اعتبارنامه‌های کاربری، جعل هویت کاربران مجاز، یا توقف پاسخ‌گویی سرور شود. با این حال، برای هر یک از CVEها، بردار حمله خاص و پیش‌شرط‌های لازم به‌طور کامل تشریح نشده است. به‌عنوان مثال، برای CVE-2026-58080 ذکر شده که کپی پیکربندی سرور، RoleMapper را حفظ نمی‌کند، اما جزئیات فنی در مورد نحوه بهره‌برداری و تأثیر دقیق آن بر کنترل دسترسی مبتنی بر نقش، مبهم باقی مانده است.

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

• عدم وجود جزئیات کامل برای CVE-2026-60007 و CVE-2026-61387 در متن advisory
• عدم پوشش نسخه‌های قدیمی‌تر از 0.6.0 و عدم وجود به‌روزرسانی برای آن‌ها
• ناقص بودن اطلاعات برای برخی CVEها مانند CVE-2026-63248
• نیاز به ارجاع به منابع تکمیلی برای درک کامل آسیب‌پذیری‌ها

شاخص‌های اندازه‌گیری و موفقیت

برای سنجش پیشرفت در رفع آسیب‌پذیری‌های Eclipse Milo، تعریف شاخص‌های عینی و قابل اندازه‌گیری ضروری است. این شاخص‌ها باید بر اساس توصیه‌های CISA و اطلاعات مندرج در advisory (ICSA-26-288-01) تدوین شوند. از تعیین اهداف عددی بدون پشتوانه یا استناد به آمارهای غیرمستند خودداری کنید. شاخص‌های پیشنهادی در ادامه، عمدتاً کیفی و مبتنی بر اقدامات قابل تأیید هستند.

نخستین شاخص، درصد سیستم‌هایی است که به نسخه 1.1.5 یا بالاتر ارتقا یافته‌اند. این شاخص باید به تفکیک برای هر نسخه آسیب‌پذیر (0.6.x و 1.0.x تا 1.1.4) محاسبه شود. از آنجا که برای نسخه‌های 0.6.x هیچ به‌روزرسانی منتشر نشده و مهاجرت به 1.1.5 الزامی است، این معیار باید شامل برنامه مهاجرت نیز باشد. توصیه می‌شود این درصد به صورت ماهانه پایش و در گزارش‌های مدیریتی منعکس شود.

شاخص دوم، کاهش سطح حمله است. این شاخص را می‌توان از طریق ممیزی منظم پیکربندی سرورهای OPC UA، غیرفعال‌سازی نقاط پایانی غیرضروری (مانند None/None) و اعمال سیاست‌های دسترسی مبتنی بر نقش ارزیابی کرد. همچنین باید اطمینان حاصل شود که RoleMapper به درستی در پیکربندی‌های کپی‌شده حفظ می‌شود. این اقدامات به طور مستقیم تأثیر آسیب‌پذیری‌های مرتبط با مجوزها را کاهش می‌دهد.

شاخص سوم، زمان پاسخ به آسیب‌پذیری است. این شاخص شامل زمان بین انتشار advisory و اعمال وصله یا اقدامات کاهشی در محیط‌های عملیاتی است. برای اندازه‌گیری دقیق، لازم است فرآیندهای مدیریت حادثه و ارتباط با تیم‌های امنیتی مستند شود. همچنین توصیه می‌شود شاخصی برای پایش مداوم منابع حافظه و تشخیص نشت حافظه (Memory Leak) در سرورها تعریف شود، زیرا این امر به شناسایی حملات احتمالی DoS کمک می‌کند.

در نهایت، برای هر شاخص باید آستانه‌های قابل قبول تعریف شود. به عنوان مثال، درصد ارتقا باید در بازه زمانی مشخص به 100 درصد برسد. با این حال، این آستانه‌ها باید بر اساس تحلیل ریسک و ظرفیت سازمان تعیین شوند و نه صرفاً بر اساس اعداد دلخواه. توصیه می‌شود این شاخص‌ها در قالب یک داشبورد امنیتی تجمیع و به طور دوره‌ای بازبینی شوند.

• درصد سیستم‌های ارتقا یافته به نسخه 1.1.5 یا بالاتر، به تفکیک نسخه‌های آسیب‌پذیر.
• کاهش سطح حمله از طریق ممیزی پیکربندی و اعمال حداقل دسترسی‌ها.
• زمان پاسخ به آسیب‌پذیری از انتشار advisory تا اعمال وصله یا اقدامات کاهشی.
• پایش مستمر نشت حافظه و منابع برای شناسایی حملات احتمالی DoS.

1. تدوین فهرست دارایی‌های دارای Eclipse Milo و تعیین نسخه دقیق هر یک.
2. اولویت‌بندی ارتقا بر اساس نسخه‌های آسیب‌پذیر و اهمیت سیستم‌ها.
3. اجرای ممیزی امنیتی برای بررسی پیکربندی‌های RoleMapper و نقاط پایانی.
4. ایجاد فرآیند گزارش‌دهی و پیگیری برای رفع سریع آسیب‌پذیری‌ها.

عملیاتی‌سازی و اقدامات دفاعی

با توجه به شناسایی پنج آسیب‌پذیری در Eclipse Milo تا نسخه 1.1.4، نخستین اقدام دفاعی، ارتقای فوری به نسخه 1.1.5 است. این نسخه توسط بنیاد Eclipse به‌عنوان اصلاح‌کننده تمامی موارد اعلام شده معرفی شده است. برای کاربران نسخه‌های 0.6.x، هیچ به‌روزرسانی اصلاحی منتشر نشده و بنابراین مهاجرت به نسخه 1.1.5 یا بالاتر الزامی است. پیش از اعمال ارتقا، ارزیابی تأثیر و تحلیل ریسک مطابق توصیه CISA ضروری است.

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

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

توجه: اقدامات فوق صرفاً مبتنی بر توصیه‌های مندرج در advisory CISA است و هرگونه اقدام تکمیلی نیازمند تحلیل ریسک مستقل و منابع معتبر دیگر است.

• ارتقا به نسخه 1.1.5 یا بالاتر برای تمامی نصب‌های آسیب‌پذیر
• مهاجرت از نسخه‌های 0.6.x به 1.1.5 یا بالاتر
• محدودسازی دسترسی شبکه و قرار دادن سیستم‌ها پشت فایروال
• استفاده از VPN برای دسترسی از راه دور با به‌روزرسانی منظم
• اجرای توصیه‌های CISA برای دفاع عمیق و پایش مستمر

1. شناسایی تمامی سیستم‌های دارای Eclipse Milo و تعیین نسخه دقیق آن‌ها
2. برنامه‌ریزی برای ارتقا به نسخه 1.1.5 در پنجره‌های نگهداری مجاز
3. اعمال محدودیت‌های شبکه برای جلوگیری از دسترسی غیرمجاز
4. پیکربندی VPN با آخرین نسخه و اطمینان از به‌روزرسانی آن
5. مستندسازی اقدامات و گزارش فعالیت‌های مشکوک به CISA