ارزیابی آسیب‌پذیری PCB یک بررسی امنیتی مجاز برای سخت‌افزار، فریمور، رابط‌های فیزیکی، مرزهای اعتماد، فرآیند آماده‌سازی و مسیر به‌روزرسانی یک دستگاه الکترونیکی است. هدف آن شناسایی ضعف‌های قابل بهره‌برداری و تعریف اقدامات اصلاحی مبتنی بر شواهد است؛ نه اینکه جایگزین DFM، آزمون‌های قابلیت اطمینان، گواهی‌های قانونی یا آزمون کامل نفوذ سیستم شود.
نکات کلیدی
- کل دستگاه را ارزیابی کنید، نه فقط برد PCB خام را. رفتار امنیتی از ترکیب سخت‌افزار، فریمور، نرم‌افزار، محفظه، ارتباطات و عملیات شکل می‌گیرد.
- پیش از انتخاب آزمون‌ها، با دارایی‌ها، دسترسی مهاجم، مرزهای اعتماد و سناریوهای سوءاستفاده شروع کنید.
- پورت‌های دیباگ، حالت‌های بوت، حافظه خارجی، مسیرهای به‌روزرسانی، اعتبارنامه‌ها، ذخیره‌سازی کلیدها و فرآیند آماده‌سازی تولید باید به‌صورت مشخص بررسی شوند.
- یک کانکتور غیرفعال‌شده به معنی غیرفعال بودن رابط نیست و ترافیک رمزگذاری‌شده نیز اثباتی برای مدیریت امن کلیدها محسوب نمی‌شود.
- یافته‌ها را بر اساس دسترسی واقعی، قابلیت بهره‌برداری، اثر، تعداد دستگاه‌های تحت تأثیر، امکان تشخیص و بازیابی رتبه‌بندی کنید، نه فقط بر اساس یک برچسب عمومی شدت.
- اصلاحات و شواهد آزمون مجدد را بخشی از فرآیند عرضه محصول بدانید؛ اسکن آسیب‌پذیری بدون بسته‌شدن موارد فقط فهرستی از ریسک‌هاست.
چه مواردی در ارزیابی آسیب‌پذیری PCB شامل می‌شود؟
دامنه بررسی باید از سطح حمله محصول پیروی کند. برای یک دستگاه نهفته یا متصل، این موارد معمولاً شامل موارد زیر است:
- پردازنده‌ها، عناصر امن، حافظه‌ها، منطق قابل برنامه‌ریزی و تنظیمات بوت
- رابط‌های دیباگ، برنامه‌ریزی، تست، سرویس و بازیابی
- رابط‌های سیمی، بی‌سیم، رسانه قابل جداسازی، حسگر، عملگر و نگهداری
- فریمور نصب‌شده، بوت‌لودرها، بسته‌های به‌روزرسانی، تنظیمات و تصاویر بازیابی
- اعتبارنامه‌ها، کلیدهای رمزنگاری، گواهی‌ها، شناسه‌ها و داده‌های حساس کاربر یا عملیاتی
- برنامه‌ریزی تولید، تزریق کلید، شماره‌گذاری سریال، تست، تعمیر، اسقاط و فرآیندهای تعمیرات
- محفظه و فرضیات مربوط به دسترسی فیزیکی که از برد محافظت می‌کنند یا آن را در معرض خطر قرار می‌دهند
- برنامه‌های همراه، سرویس‌های ابری، درگاه‌ها و کنترل‌های عملیاتی، زمانی که بر امنیت دستگاه اثر دارند
کیفیت ساخت PCB می‌تواند بر قابلیت اطمینان و مقاومت در برابر دستکاری اثر بگذارد، اما امنیت سایبری را نمی‌توان از جنس لایه، کلاس IPC، بازرسی X-ray یا آزمون الکتریکی نتیجه‌گیری کرد. برعکس، وجود قابلیت بوت امن نیز اثبات نمی‌کند که دسترسی دیباگ، کلیدهای آماده‌سازی، رفتار بازیابی یا مجوز به‌روزرسانی امن هستند.
ابتدا دارایی‌ها، مهاجمان و مرزهای اعتماد را تعریف کنید
آزمون بدون مدل تهدید، فعالیت زیادی ایجاد می‌کند اما پوشش ضعیفی دارد. ابتدا مشخص کنید چه چیزهایی باید محافظت شوند و چه کسی ممکن است به آن‌ها دسترسی پیدا کند.
| پرسش | نمونه مواردی که باید ثبت شوند | دلیل تأثیر بر ارزیابی |
|---|---|---|
| دارایی‌ها چه هستند؟ | یکپارچگی فریمور، کلیدهای امضا، هویت دستگاه، اعتبارنامه‌ها، داده‌های شخصی، عملکردهای ایمنی، کالیبراسیون، مالکیت فکری | میزان اثر و شواهد موردنیاز را مشخص می‌کند |
| مهاجم چه کسی است؟ | کاربر راه دور، کاربر شبکه محلی، تکنسین سرویس، مالک، فرد داخلی زنجیره تأمین، فرد دارای دسترسی فیزیکی موقت یا دائمی | فرضیات دسترسی و تجهیزات واقعی را مشخص می‌کند |
| مرزهای اعتماد کجا هستند؟ | گذرگاه MCU به فلش خارجی، تحویل از برنامه به بوت‌لودر، آماده‌سازی کارخانه تا دستگاه، لینک دستگاه تا ابر، رابط سرویس | مشخص می‌کند احراز هویت، یکپارچگی، محرمانگی و مجوزها کجا باید بررسی شوند |
| کدام وضعیت‌ها مهم هستند؟ | تولید، اولین بوت، عملکرد عادی، به‌روزرسانی، بازیابی، سرویس، خارج‌سازی از چرخه استفاده | کنترل‌های امنیتی اغلب با تغییر مرحله چرخه عمر تغییر می‌کنند |
| پیامد چیست؟ | افشای داده، اجرای کد غیرمجاز، عملکرد ناامن، نفوذ پایدار، آسیب به کل ناوگان، عدم سرویس‌دهی، دستگاه غیرقابل بازیابی | شدت و اولویت اصلاح را تعیین می‌کند |
دامنه ارزیابی باید مشخص کند که آیا روش‌های مخرب، باز کردن پکیج قطعات، تزریق خطا، آزمون رادیویی، آزمون ابری یا سرویس‌های شخص ثالث مجاز هستند یا خیر. آزمون باید فقط روی سیستم‌های متعلق به سازمان یا دارای مجوز صریح و در محیط کنترل‌شده انجام شود.
ماتریس بررسی سطح حمله سخت‌افزار
بررسی برد باید هر قابلیت در معرض دسترسی را به یک هدف امنیتی و روش اعتبارسنجی متصل کند.
| سطح | پرسش امنیتی | شواهد تأیید دفاعی |
|---|---|---|
| رابط‌های دیباگ و تست | آیا JTAG، SWD، UART، boundary-scan یا حالت‌های تست سازنده می‌توانند کنترل، حافظه یا اسرار را خارج از سرویس مجاز آشکار کنند؟ | بررسی شماتیک و PCB، تنظیمات حالت تولید، نتیجه کنترل دسترسی، آزمون چرخه عمر، مسیر بازیابی مستند |
| تنظیمات بوت و بازیابی | آیا پایه‌های بوت، پین‌های بازیابی، رسانه قابل جداسازی یا منابع بوت جایگزین می‌توانند زنجیره اعتماد را دور بزنند؟ | ماتریس حالت بوت، بررسی تصویر مجاز، سیاست بازیابی، فرضیات دسترسی فیزیکی |
| حافظه خارجی | آیا کد اجرایی، تنظیمات، اعتبارنامه‌ها یا داده‌های حساس در برابر خواندن یا جایگزینی غیرمجاز محافظت شده‌اند؟ | طبقه‌بندی داده، کنترل یکپارچگی/اصالت، طراحی جداسازی کلید، آزمون قطع برق و بازیابی |
| هویت دستگاه و کلیدها | آیا اسرار در صورت نیاز یکتا هستند، هنگام ذخیره و آماده‌سازی محافظت می‌شوند، قابل لغو هستند و در لاگ‌ها یا تست‌های معمول افشا نمی‌شوند؟ | معماری آماده‌سازی، سوابق دسترسی، بررسی یکتایی، چرخه عمر کلید/گواهی و برنامه لغو |
| باس‌های داخلی و نقاط تست در معرض | آیا باس‌های قابل دسترس می‌توانند اسرار را آشکار کنند یا تغییر وضعیت غیرمجاز ایجاد کنند؟ | بررسی دسترسی برد، فهرست رابط‌ها، نیاز به احراز هویت یا حفاظت رمزنگاری، فرضیات محفظه |
| حسگرها و عملگرها | آیا ورودی‌های غیرقابل اعتماد، حسگرهای جعلی یا فرمان‌های غیرمجاز می‌توانند رفتار ناامن یا سطح دسترسی بالا ایجاد کنند؟ | اعتبارسنجی ورودی، بررسی حالت خطا، آزمون مجوز، شواهد وضعیت امن |
| واکنش در برابر دستکاری | آیا محصول به شواهد دستکاری، تشخیص دستکاری یا واکنش نیاز دارد و آیا طراحی به هدف اعلام‌شده می‌رسد؟ | ردیابی نیازمندی، بررسی محفظه/برد، آزمون واکنش و بازیابی |
| کنترل تغذیه و ریست | آیا رفتار غیرعادی تغذیه، ریست، کلاک یا نگهداری می‌تواند دستگاه را وارد وضعیت ناامن کند؟ | آزمون افت ولتاژ/ریست، بررسی fail-secure، شواهد بازیابی احراز هویت‌شده |
حذف یک هدر ممکن است راحتی استفاده را کاهش دهد، اما اثبات نمی‌کند که رابط زیرین غیرقابل دسترسی است. همچنین پوشاندن نقاط تست با پوشش محافظ یا انتقال مسیرها به لایه‌های داخلی نباید جایگزین احراز هویت، کنترل چرخه عمر، ذخیره‌سازی محافظت‌شده کلید یا بررسی یکپارچگی فریمور شود.
ارزیابی فریمور، بوت امن و به‌روزرسانی
ارزیابی فریمور باید تصویر نصب‌شده و تمام مسیرهای مجازی جایگزینی، بازیابی یا پیکربندی آن را پوشش دهد.
یکپارچگی بوت و زمان اجرا
- ریشه اعتماد را مشخص کنید و تعیین کنید کدام بخش هر مرحله را بررسی می‌کند.
- بررسی کنید فقط فریمور مجاز در حالت‌های عادی، به‌روزرسانی، سرویس و بازیابی پذیرفته شود.
- بررسی کنید هنگام شکست اعتبارسنجی، قطع برق یا خراب‌شدن فراداده چه اتفاقی رخ می‌دهد.
- اطمینان حاصل کنید رفتار دیباگ و سرویس نمی‌تواند سیاست بوت را به‌صورت مخفی دور بزند.
- تنظیمات حیاتی امنیتی را محافظت کنید و روش تشخیص تغییرات غیرمجاز را تعریف کنید.
به‌روزرسانی و بازیابی
- منبع به‌روزرسانی را احراز هویت کنید و یکپارچگی و اصالت بسته را پیش از نصب بررسی کنید.
- رفتار ضد بازگشت نسخه را تعریف کنید تا نسخه‌های قدیمی آسیب‌پذیر رد شوند.
- شکست به‌روزرسانی باید بدون پذیرش تصویرهای دلخواه یا بدون امضا قابل بازیابی باشد.
- هویت دستگاه، وضعیت امنیتی و داده‌های ضروری کاربر را در فرآیند بازیابی مجاز حفظ کنید.
- نسخه نصب‌شده را ثبت کنید و روشی برای تعیین وضعیت امنیتی در پشتیبانی و پاسخ به رخداد فراهم کنید.
NIST SP 800-193 مقاومت فریمور را بر پایه جلوگیری از تغییر غیرمجاز، تشخیص تغییر و بازیابی امن تعریف می‌کند. این سه نتیجه از یک گزینه ساده «بوت امن فعال است» ارزشمندتر هستند.
صفحه برنامه‌ریزی IC در APTPCB رابط تولید را توضیح می‌دهد؛ مالک محصول باید تصویر تأییدشده، قوانین اعتبارسنجی، مرزهای اعتبارنامه و مرجع انتشار را ارائه کند.
امنیت تولید و آماده‌سازی
امنیت ممکن است پس از انتشار طراحی، در صورتی که فرآیند تولید فریمور، اعتبارنامه‌ها، مواد امضا، شناسه‌ها یا دسترسی دیباگ را در معرض قرار دهد، تضعیف شود.
| مرحله تولید | پرسش‌های کنترلی | شواهد مفید |
|---|---|---|
| دریافت داده | چه کسانی به فایل‌های باینری، تنظیمات، کلیدها، گواهی‌ها و فایل‌های مشتری دسترسی دارند؟ | تعریف نقش، روش انتقال، سیاست دسترسی و نگهداری |
| برنامه‌ریزی | آیا تصویر تأییدشده شناسایی، بررسی یکپارچگی و به سخت‌افزار صحیح متصل شده است؟ | چک‌سام یا شناسه تأییدشده فایل، رکورد تولید، تنظیمات پروگرامر، گزارش نتیجه |
| آماده‌سازی کلید یا گواهی | آیا اسرار طبق معماری امنیتی محصول تولید، منتقل، تزریق و حذف می‌شوند؟ | جریان آماده‌سازی، جداسازی دسترسی، نتیجه یکتایی، گزارش ممیزی، مدیریت استثنا |
| تست | آیا فیکسچرها، اسکریپت‌ها، لاگ‌ها، واحدهای مرجع یا فرمان‌های سرویس می‌توانند اسرار را افشا کنند یا وضعیت سطح بالا را باقی بگذارند؟ | بسته تست بررسی‌شده، لاگ‌های حذف اطلاعات حساس، کنترل دسترسی فیکسچر، بررسی وضعیت پس از تست |
| شماره‌گذاری سریال | آیا هویت دستگاه، برچسب‌ها، MAC Address، گواهی‌ها و رکوردهای پایگاه داده درست مرتبط شده‌اند؟ | شجره‌نامه واحد و بررسی تکرار/تعارض |
| بازکاری و تعمیر | آیا دستگاه‌های جایگزین‌شده می‌توانند به‌صورت امن دوباره آماده‌سازی شوند و هویت‌های قدیمی لغو یا قرنطینه شوند؟ | دستورالعمل کنترل‌شده بازکاری، مجوز، رکورد قبل/بعد |
| اسقاط و مواد اضافی | دستگاه‌های برنامه‌ریزی‌شده، بردهای معیوب، برچسب‌ها و حافظه‌های حساس چگونه نابود یا بازگردانده می‌شوند؟ | رکورد تعیین تکلیف و روش مورد تأیید مشتری |
| انتشار | آیا هر واحد ارسال‌شده دارای فریمور، تنظیمات، وضعیت امنیتی و نتیجه تست تأییدشده است؟ | رکورد انتشار واحد یا دسته با وضعیت استثنا |
کلیدهای امضای تولید را فقط به این دلیل که کارخانه قراردادی نیاز به بارگذاری فریمور دارد ارسال نکنید. معماری امنیتی باید اختیارهای در معرض خطر را به حداقل برساند، نقش‌ها را جدا کند و هر سطح دسترسی لازم را شفاف تعریف کند. از خدمات پشتیبانی PCBA و تست و کنترل کیفیت برای تعریف تحویل تولید استفاده کنید، سپس کنترل‌های دقیق را در قرارداد و پیشنهاد قیمت تأیید کنید.
گردش کار ارزیابی آسیب‌پذیری
1. برنامه‌ریزی ارزیابی
نسخه‌های سخت‌افزار و نرم‌افزار هدف، واحدهای تست، وضعیت‌های محصول، حساب‌ها، رابط‌ها، سرویس‌های پشتیبان، روش‌های ممنوع، قوانین مدیریت داده، قالب گزارش و زمان‌بندی اصلاحات را مشخص کنید. پیکربندی تست‌شده را ثابت نگه دارید تا یافته‌ها قابل تکرار باشند.
2. بررسی معماری و داده‌های طراحی
نمودارهای بلوکی، جریان داده، شماتیک، فایل‌های PCB، BOM، معماری پردازنده و حافظه، زنجیره بوت، طراحی به‌روزرسانی، راهبرد دیباگ، چرخه عمر کلید، جریان تولید و نیازمندی‌های امنیتی را بررسی کنید. این بررسی اغلب پیش از شروع آزمون آزمایشگاهی کنترل‌های مفقود را آشکار می‌کند.
3. ایجاد فهرست سطح حمله
رابط‌های فیزیکی، داخلی، سیمی، بی‌سیم، برنامه، ابر، به‌روزرسانی، بازیابی و تولید را فهرست کنید. ثبت کنید کدام رابط‌ها در هر مرحله چرخه عمر فعال هستند و چه کنترل‌های احراز هویت، مجوز، یکپارچگی، محرمانگی و ثبت رویداد اعمال می‌شوند.
4. انجام آزمون فنی مجاز
ترکیبی مبتنی بر ریسک از بررسی پیکربندی، آزمون رابط، تحلیل فریمور، آزمون به‌روزرسانی و بازیابی، بررسی اعتبارنامه، آزمون ارتباطات، آزمون دسترسی فیزیکی و بررسی حالت‌های شکست مورد انتظار استفاده کنید. شواهد کافی برای بازتولید یافته را حفظ کنید بدون اینکه جزئیات حساس بهره‌برداری را منتشر کنید.
5. اولویت‌بندی و اصلاح
برای هر یافته، دارایی تحت تأثیر، پیش‌نیازها، سطح دسترسی، اثر، نسخه‌های درگیر، شواهد، کنترل پیشنهادی، مالک، تاریخ هدف و کنترل‌های جبرانی را ثبت کنید. علت اصلی را در معماری، سخت‌افزار، فریمور، آماده‌سازی یا عملیات اصلاح کنید، نه اینکه فقط رابط مشاهده‌شده را پنهان کنید.
6. آزمون مجدد و انتشار
مسیر اصلاح‌شده و وضعیت‌های مرتبط را دوباره تست کنید، سپس مدل‌های تهدید، نیازمندی‌ها، دستورالعمل‌های تولید، رویه‌های سرویس و تست‌های بازگشتی را به‌روزرسانی کنید. انتشار باید نشان دهد کدام یافته‌ها بسته، پذیرفته، کاهش‌یافته یا توسط مالک مجاز به تعویق افتاده‌اند.
آسیب‌پذیری‌های سخت‌افزاری چگونه باید اولویت‌بندی شوند؟
CVSS می‌تواند برای ارتباط دادن یافته‌های مشابه نرم‌افزار مفید باشد، اما تصمیم‌گیری در دستگاه‌های سخت‌افزاری و نهفته به دسترسی فیزیکی، مقیاس ناوگان، قابلیت تعمیر، اثر ایمنی و مواجهه تولید نیز وابسته است.
| عامل | پرسش‌های بررسی |
|---|---|
| دسترسی | آیا بهره‌برداری از راه دور، شبکه محلی، رادیویی نزدیک، دسترسی فیزیکی موقت، دائمی یا زنجیره تأمین است؟ |
| پیش‌نیازها | آیا به اعتبارنامه، وضعیت سطح بالا، باز کردن محفظه، تجهیزات تخصصی یا وضعیت خاص محصول نیاز دارد؟ |
| اثر | آیا می‌تواند اسرار را افشا کند، کد غیرمجاز نصب کند، رفتار ایمنی را تغییر دهد، پس از ریست/به‌روزرسانی باقی بماند یا بازیابی را غیرفعال کند؟ |
| مقیاس | آیا ضعف فقط یک واحد، یک دسته، یک جمعیت کلیدی، یک نسخه فریمور یا کل ناوگان را تحت تأثیر قرار می‌دهد؟ |
| قابلیت تشخیص | آیا مالک، دستگاه، سرویس یا سیستم تولید می‌تواند بهره‌برداری یا تغییر پیکربندی را تشخیص دهد؟ |
| بازیابی | آیا دستگاه می‌تواند به‌صورت امن به‌روزرسانی، ریست، کلیدگذاری مجدد، تعمیر یا فراخوانی شود؟ آیا اعتماد حفظ می‌شود؟ |
| قدرت شواهد | آیا نتیجه یک مسیر بهره‌برداری تأییدشده، ضعف طراحی، فرضیه پیکربندی تأییدنشده یا نگرانی نظری است؟ |
یک حمله دشوار از نظر فیزیکی می‌تواند همچنان بحرانی باشد اگر استخراج یک کلید باعث آسیب به کل خانواده محصول شود. یک مشکل قابل دسترسی از راه دور نیز ممکن است رتبه پایین‌تری داشته باشد اگر هیچ دارایی حساسی را تحت تأثیر قرار ندهد و به‌طور قابل اعتماد محدود شود. شدت باید بر اساس مدل واقعی محصول تعیین شود.
خطاهای رایج در ارزیابی
| روش ضعیف | دلیل شکست | رویکرد بهتر |
|---|---|---|
| در نظر گرفتن DFM به‌عنوان ارزیابی امنیت | تولیدپذیری، مجوز، یکپارچگی فریمور، اعتبارنامه یا رفتار به‌روزرسانی را بررسی نمی‌کند | بررسی DFM و امنیت سایبری را به‌عنوان دروازه‌های جدا اما هماهنگ اجرا کنید |
| فقط اسکن سرویس‌های شبکه | رابط‌های فیزیکی، فریمور، حافظه، بازیابی و آماده‌سازی بررسی نمی‌شوند | از مدل دستگاه شامل سخت‌افزار، فریمور، ارتباطات، برنامه‌ها و عملیات استفاده کنید |
| فرض اینکه عنصر امن همه مشکلات را حل می‌کند | یکپارچه‌سازی، آماده‌سازی، سیاست دسترسی، طراحی به‌روزرسانی و چرخه عمر کلید ممکن است شکست بخورند | کل زنجیره اعتماد و چرخه عمر عملیاتی را بررسی کنید |
| غیرفعال کردن دیباگ فقط در مستندات | پیکربندی تولید یا وضعیت‌های دیگر چرخه عمر ممکن است همچنان دسترسی ایجاد کنند | وضعیت واقعی تولید و مسیرهای سرویس/بازیابی را تست کنید |
| استفاده از اعتبارنامه یا کلید مشترک | یک افشا می‌تواند دستگاه‌های زیادی را تحت تأثیر قرار دهد و لغو را دشوار کند | از یکتایی، چرخش، لغو و ممیزی متناسب با محصول استفاده کنید |
| گزارش یافته‌ها بدون آزمون مجدد | تیم نمی‌تواند اثربخشی اصلاح یا جلوگیری از بازگشت مشکل را ثابت کند | شواهد بسته‌شدن و تست بازگشتی هدفمند را الزامی کنید |
| انتشار گسترده جزئیات حساس بهره‌برداری | خود گزارش به یک ریسک تبدیل می‌شود | جزئیات فنی را محدود به دریافت‌کنندگان مجاز کنید و خلاصه مدیریتی جداگانه بسازید |
چک‌لیست RFQ ارزیابی آسیب‌پذیری PCB
زمینه محصول و تهدید
- هدف دستگاه، کاربران، محیط استفاده، اثر ایمنی، اتصال‌پذیری و سطح دسترسی فیزیکی مورد انتظار
- دارایی‌ها، مرزهای اعتماد، مدل مهاجم، وضعیت‌های محصول، مقیاس ناوگان و انتظارهای بازیابی
- الزامات مشتری، قانونی، صنعتی، حریم خصوصی و امنیت سایبری همراه با نسخه آن‌ها
بسته فنی
- نمودار بلوکی، نمودار جریان داده، شماتیک، داده PCB، BOM، معماری پردازنده/حافظه و فهرست رابط‌ها
- نسخه‌های فریمور و بوت‌لودر، طراحی به‌روزرسانی/بازیابی، طراحی دیباگ/سرویس، تنظیمات و اجزای شخص ثالث
- محفظه، کانکتورها، نقاط تست، مسیرهای برنامه‌ریزی، عناصر امن، حافظه‌های خارجی و طراحی ذخیره کلید
تولید و چرخه عمر
- گردش کار برنامه‌ریزی و آماده‌سازی، تصاویر تأییدشده، شناسه‌ها، گواهی‌ها، کلیدها، شماره‌گذاری، لاگ‌ها و مرزهای دسترسی
- اولین بوت، استفاده عادی، سرویس، تعمیر، بازکاری، بازنشانی کارخانه، انتقال مالکیت، خروج از سرویس و رفتار اسقاط
- تأمین قطعات، کنترل تغییرات، دریافت آسیب‌پذیری، دوره پشتیبانی نرم‌افزار، سیاست به‌روزرسانی و مالکیت پاسخ به رخداد
ارزیابی و خروجی‌ها
- روش‌های تست مجاز، روش‌های ممنوع، واحدهای تست، محدودیت آزمایشگاه، مدیریت داده و قوانین افشا
- قالب یافته‌ها، روش شدت‌بندی، شواهد بازتولید، راهنمای اصلاح، دامنه آزمون مجدد و خلاصه مدیریتی
- نگاشت استانداردها، ماتریس ردیابی، پذیرش ریسک باز و شواهد انتشار
برای زمینه تولید از صفحه PCB تجهیزات امنیتی و برای پرسش‌های مربوط به مواد تأییدشده و قابلیت ردیابی از تأمین قطعات استفاده کنید. تأمین‌کننده تولید می‌تواند ساخت کنترل‌شده و برنامه‌ریزی را پشتیبانی کند، اما برای ارزیابی یا گواهی امنیتی محصول ممکن است همچنان به آزمایشگاه امنیتی تخصصی یا معتبر نیاز باشد.
استانداردها و مرز مسئولیت
- NISTIR 8259A — مبنای قابلیت‌های اصلی امنیت سایبری دستگاه‌های IoT
- NIST SP 800-115 — راهنمای فنی تست و ارزیابی امنیت اطلاعات
- NIST SP 800-193 — دستورالعمل‌های مقاومت فریمور پلتفرم
- ETSI EN 303 645 V3.1.3 — امنیت سایبری برای اینترنت اشیای مصرفی: الزامات پایه
- IEC 62443-4-1 — الزامات چرخه عمر توسعه امن محصول
- IEC 62443-4-2 — الزامات امنیت فنی برای اجزای IACS
- ISO/SAE 21434 — مهندسی امنیت سایبری خودروهای جاده‌ای
- OWASP IoT Security Testing Guide — روش‌شناسی تست و فهرست موارد آزمون IoT
فقط استانداردها، نسخه‌ها، پروفایل‌ها و مقررات موردنیاز برای محصول و بازار هدف را اعمال کنید. تأمین‌کننده PCB/PCBA مسئول تولید مطابق داده‌های تأییدشده و کنترل‌های قراردادی است. مالک محصول مسئولیت مدل تهدید، معماری امنیتی، نرم‌افزار، اختیار کلیدها، مدیریت آسیب‌پذیری، انطباق قانونی، اعتبارسنجی سیستم و پاسخ میدانی را حفظ می‌کند.
پرسش‌های متداول
آیا ارزیابی آسیب‌پذیری PCB همان بررسی DFM است؟
خیر. DFM بررسی می‌کند که آیا برد با ساختار و فرآیند پیشنهادی قابل تولید است یا خیر. ارزیابی آسیب‌پذیری بررسی می‌کند که آیا سخت‌افزار، فریمور، رابط‌ها، اعتبارنامه‌ها، به‌روزرسانی‌ها، آماده‌سازی و وضعیت‌های کاری ضعف امنیتی قابل بهره‌برداری ایجاد می‌کنند یا خیر.
آیا می‌توان یک PCB خام را تست نفوذ کرد؟
یک PCB خام را می‌توان از نظر ویژگی‌های طراحی و ناهنجاری‌های ساخت بررسی کرد، اما تست نفوذ معنادار معمولاً به دستگاه مونتاژشده، فریمور تولیدی، محفظه، رابط‌ها، اعتبارنامه‌ها و سرویس‌های پشتیبان نیاز دارد. مرز امنیتی بزرگ‌تر از طراحی برد است.
کدام رابط‌ها باید در یک دستگاه نهفته بررسی شوند؟
تمام رابط‌های فیزیکی، داخلی، سیمی، بی‌سیم، دیباگ، برنامه‌ریزی، تست، سرویس، بازیابی، رسانه قابل جداسازی، حسگر و عملگر را فهرست کنید. بررسی کنید کدام رابط‌ها در حالت تولید، عادی، سرویس، به‌روزرسانی، بازیابی و خروج از سرویس فعال هستند.
آیا بوت امن دستگاه را امن می‌کند؟
خیر. بوت امن می‌تواند از زنجیره اعتماد هنگام شروع محافظت کند، اما امنیت به حفاظت کلید، مجوز به‌روزرسانی، سیاست ضد بازگشت، بازیابی، کنترل دیباگ، نرم‌افزار زمان اجرا، اعتبارنامه‌ها، ارتباطات، آماده‌سازی و پاسخ به رخداد نیز وابسته است.
آیا پورت‌های دیباگ باید از PCBهای تولیدی حذف شوند؟
این تصمیم وابسته به محصول است. حذف کانکتور ممکن است مواجهه را کاهش دهد، اما رابط زیرین را غیرفعال نمی‌کند. پیکربندی چرخه عمر تولید، احراز هویت، سرویس مجاز، بازیابی و تأیید پس از برنامه‌ریزی باید همراه هم طراحی و تست شوند.
ارزیابی آسیب‌پذیری سخت‌افزار هر چند وقت باید تکرار شود؟
زمانی که سخت‌افزار، فریمور، بوت‌لودرها، قطعات، تأمین‌کنندگان، آماده‌سازی، سرویس‌های ابری، رابط‌ها، فرضیات تهدید، مقررات یا سایت‌های تولید تغییر می‌کنند، ارزیابی باید تکرار یا به‌روزرسانی شود؛ همچنین هنگام کشف آسیب‌پذیری‌های جدید در اجزا یا نرم‌افزارهای موجود.
گزارش ارزیابی امنیتی باید چه شواهدی داشته باشد؟
باید پیکربندی تست‌شده، دامنه، فرضیات، روش‌ها، دارایی‌ها و نسخه‌های تحت تأثیر، پیش‌نیازها، اثر، شواهد قابل تکرار، منطق شدت، اصلاح، مالک، وضعیت و نتیجه آزمون مجدد را مشخص کند. جزئیات فنی حساس باید توزیع کنترل‌شده داشته باشند.
درخواست بررسی تولید امن
بسته سخت‌افزاری منتشرشده، دامنه برنامه‌ریزی و آماده‌سازی، شناسه‌های فریمور تأییدشده، نیازمندی‌های ردیابی، قوانین مدیریت موارد حساس امنیتی، تعداد تولید و شواهد موردنیاز را ارسال کنید. APTPCB می‌تواند شکاف‌های تحویل تولید و PCBA را بررسی کند؛ تست امنیت سایبری محصول تابع دامنه توافق‌شده و مرجع مسئول امنیتی است.