Оцінювання вразливостей PCB — це авторизована перевірка безпеки електронного пристрою, яка охоплює апаратне забезпечення, мікропрограмне забезпечення, фізичні інтерфейси, межі довіри, процес підготовки до експлуатації та шлях оновлення. Його мета — виявити вразливості, які можна використати, і визначити заходи усунення на основі доказів, а не замінити DFM, випробування на надійність, сертифікацію відповідності нормативам або повноцінний тест проникнення системи.
Ключові висновки
- Оцінюйте весь пристрій, а не лише голу PCB. Поведінка безпеки формується апаратним забезпеченням, мікропрограмним забезпеченням, програмним забезпеченням, корпусом, комунікаціями та експлуатаційними процесами.
- Перед вибором методів тестування визначте активи, доступ з боку атакувальника, межі довіри та сценарії зловживання.
- Налагоджувальні порти, завантажувальні перемички, зовнішня пам’ять, шляхи оновлення, облікові дані, зберігання ключів і виробниче програмування потребують окремої перевірки.
- Вимкнений роз’єм не означає вимкнений інтерфейс, а зашифрований трафік не є доказом безпечного керування ключами.
- Ранжуйте виявлені проблеми за реальним доступом, можливістю експлуатації, впливом, кількістю уражених пристроїв, можливістю виявлення та відновленням, а не лише за загальним рівнем критичності.
- Розглядайте усунення вразливостей і докази повторного тестування як частину процесу випуску; сканування без закриття проблем — це лише перелік ризиків.
Що включає оцінювання вразливостей PCB?
Обсяг перевірки має відповідати поверхні атаки продукту. Для вбудованого або підключеного пристрою зазвичай він включає:
- процесорні пристрої, захищені елементи, пам’ять, програмовану логіку та конфігурацію завантаження
- інтерфейси налагодження, програмування, тестування, обслуговування та відновлення
- дротові, бездротові інтерфейси, змінні носії, сенсорні, виконавчі та сервісні інтерфейси
- встановлене мікропрограмне забезпечення, завантажувачі, пакети оновлень, конфігурації та образи відновлення
- облікові дані, криптографічні ключі, сертифікати, ідентифікатори та конфіденційні користувацькі або експлуатаційні дані
- виробниче програмування, введення ключів, серіалізацію, тестування, доопрацювання, утилізацію та ремонтні процеси
- корпус і припущення щодо фізичного доступу, які захищають або відкривають плату
- супутні застосунки, хмарні сервіси, шлюзи та експлуатаційні засоби керування, якщо вони впливають на безпеку пристрою
Якість виготовлення PCB може впливати на надійність і стійкість до несанкціонованого втручання, але кібербезпеку неможливо визначити за матеріалом основи, класом IPC, рентгенівським контролем або електричними випробуваннями. Водночас наявність функції безпечного завантаження не доводить, що доступ через налагодження, ключі підготовки до виробництва, поведінка відновлення або авторизація оновлень є захищеними.
Спочатку визначте активи, атакувальників і межі довіри
Тестування без моделі загроз створює враження значного обсягу робіт, але забезпечує слабке покриття. Почніть із визначення того, що необхідно захистити, і хто може отримати доступ.
| Питання | Приклади для документування | Чому це змінює оцінювання |
|---|---|---|
| Які є активи? | Цілісність мікропрограмного забезпечення, ключі підпису, ідентичність пристрою, облікові дані, персональні дані, функції безпеки, калібрування, інтелектуальна власність | Визначає вплив і необхідні докази |
| Хто є атакувальником? | Віддалений користувач, користувач локальної мережі, сервісний інженер, власник, внутрішній учасник ланцюга постачання, особа з тимчасовим або постійним фізичним доступом | Визначає реалістичний доступ і припущення щодо обладнання |
| Де знаходяться межі довіри? | Шина MCU–зовнішня флеш-пам’ять, передача від застосунку до завантажувача, підготовка пристрою на заводі, канал пристрій–хмара, сервісний інтерфейс | Визначає місця, де необхідно перевіряти автентифікацію, цілісність, конфіденційність і авторизацію |
| Які стани мають значення? | Виробництво, перше завантаження, нормальна робота, оновлення, відновлення, сервіс, виведення з експлуатації | Засоби захисту часто змінюються залежно від етапу життєвого циклу |
| Які наслідки? | Розкриття даних, несанкціонований код, небезпечне керування, постійна компрометація, ураження всього парку пристроїв, відмова в обслуговуванні, неможливість відновлення | Визначає пріоритет критичності та усунення |
Обсяг оцінювання має чітко визначати, чи дозволені руйнівні методи, інвазивна робота з корпусом мікросхем, ін’єкція помилок, радіотестування, перевірка хмарних сервісів або послуги третіх сторін. Тестування повинно виконуватися лише на власних або явно авторизованих системах у контрольованому середовищі.
Матриця перевірки поверхні апаратної атаки
Перевірка плати має пов’язувати кожну відкриту функцію з метою безпеки та методом верифікації.
| Поверхня | Питання безпеки | Докази захисної перевірки |
|---|---|---|
| Інтерфейси налагодження та тестування | Чи можуть JTAG, SWD, UART, boundary-scan або заводські режими тестування надати контроль, доступ до пам’яті чи секретів поза авторизованим сервісом? | Перевірка схеми та PCB, конфігурація виробничого стану, результат контролю доступу, тест станів життєвого циклу, документований шлях відновлення |
| Конфігурація завантаження та відновлення | Чи можуть завантажувальні перемички, контакти відновлення, змінні носії або альтернативні джерела завантаження обійти передбачений ланцюг довіри? | Матриця станів завантаження, перевірка авторизованих образів, політика відновлення, припущення щодо фізичного доступу |
| Зовнішня пам’ять | Чи захищені виконуваний код, конфігурація, облікові дані або чутливі дані від несанкціонованого читання чи заміни? | Класифікація даних, контроль цілісності/автентичності, розділення ключів, тести втрати живлення та відновлення |
| Ідентичність пристрою та ключі | Чи є секрети унікальними там, де це потрібно, захищеними під час зберігання та програмування, відкличними та виключеними з журналів? | Архітектура підготовки, записи доступу, перевірка унікальності, життєвий цикл ключів/сертифікатів і план відкликання |
| Внутрішні шини та відкриті тестові точки | Чи можуть доступні шини розкрити секрети або дозволити несанкціоновану зміну стану? | Перевірка доступу до плати, інвентаризація інтерфейсів, необхідна автентифікація або криптографічний захист, припущення щодо корпусу |
| Сенсори та виконавчі механізми | Чи можуть ненадійні входи, підроблені сигнали сенсорів або несанкціоновані команди створити небезпечну чи привілейовану поведінку? | Перевірка вхідних даних, аналіз аварійних станів, тести авторизації, докази безпечного стану |
| Реакція на втручання | Чи потрібні продукту ознаки втручання, виявлення втручання або реакція на нього — і чи відповідає конструкція цій вимозі? | Трасування вимог, перевірка корпусу/плати, тест реакції та відновлення |
| Живлення та скидання | Чи можуть нестандартне живлення, скидання, тактовий сигнал або сервісні операції перевести пристрій у небезпечний стан? | Тестування brownout/reset-станів, перевірка безпечного завершення, докази автентифікованого відновлення |
Видалення заголовка може зменшити зручність, але не доводить, що відповідний інтерфейс недоступний. Так само покриття тестових точок захисним покриттям або перенесення трас на внутрішні шари не повинні подаватися як заміна автентифікації, контролю життєвого циклу, захищеного зберігання ключів або перевіреної цілісності мікропрограмного забезпечення.
Оцінювання мікропрограмного забезпечення, безпечного завантаження та оновлень
Оцінювання мікропрограмного забезпечення має охоплювати встановлений образ і всі авторизовані шляхи, які можуть замінити, відновити або налаштувати його.
Цілісність завантаження та виконання
- Визначте корінь довіри та компонент, який перевіряє кожний етап.
- Переконайтеся, що лише авторизоване мікропрограмне забезпечення приймається у звичайному, оновлювальному, сервісному та аварійному режимах.
- Перевірте поведінку у випадку помилки перевірки, переривання живлення або пошкодження метаданих.
- Підтвердьте, що налагодження та сервісні функції не можуть непомітно обійти політику завантаження.
- Захистіть критичні параметри безпеки та визначте спосіб виявлення несанкціонованих змін.
Оновлення та відновлення
- Автентифікуйте джерела оновлень і перевіряйте цілісність та справжність пакета перед встановленням.
- Визначте поведінку захисту від відкату, коли старі вразливі версії мають бути відхилені.
- Забезпечте можливість відновлення після невдалого оновлення без прийняття довільних або непідписаних образів.
- Зберігайте ідентичність пристрою, стан безпеки та необхідні дані користувача через затверджений процес відновлення.
- Записуйте встановлену версію та забезпечте можливість визначення стану безпеки для підтримки й реагування на інциденти.
NIST SP 800-193 описує стійкість мікропрограмного забезпечення через три основні завдання: захист від несанкціонованих змін, виявлення змін і безпечне відновлення. Ці три результати є кориснішими, ніж одна позначка «безпечне завантаження увімкнено».
Сторінка APTPCB про програмування IC описує виробничий інтерфейс; власник продукту повинен надати затверджений образ, правила перевірки, межі повноважень для облікових даних і відповідального за випуск.
Безпека виробництва та підготовки до експлуатації
Безпека може бути послаблена після випуску конструкції, якщо виробничий процес відкриває доступ до мікропрограмного забезпечення, облікових даних, матеріалів підпису, ідентифікаторів або налагоджувальних функцій.
| Етап виробництва | Контрольні питання | Корисні докази |
|---|---|---|
| Приймання даних | Хто має доступ до двійкових файлів, конфігурації, ключів, сертифікатів і файлів замовника? | Визначення ролей, метод передачі, політика доступу та зберігання |
| Програмування | Чи визначений затверджений образ, перевірена його цілісність і прив’язаний він до правильної апаратної ревізії? | Контрольна сума або затверджений ідентифікатор файлу, маршрутний лист, конфігурація програматора, журнал результатів |
| Підготовка ключів або сертифікатів | Чи створюються, передаються, вводяться та видаляються секрети відповідно до архітектури безпеки продукту? | Потік підготовки, розділення доступів, результат унікальності, аудит, обробка винятків |
| Тестування | Чи можуть стенди, скрипти, журнали, еталонні вироби або сервісні команди розкрити секрети чи залишити привілейовані стани активними? | Перевірений пакет тестування, очищені журнали, контроль доступу до стендів, перевірка стану після тестів |
| Серіалізація | Чи правильно пов’язані ідентичність пристрою, маркування, MAC-адреси, сертифікати та записи бази даних? | Генологія виробу та перевірки дублікатів/конфліктів |
| Доопрацювання та ремонт | Чи можуть замінені пристрої бути безпечно перепрограмовані, а старі ідентичності відкликані або ізольовані? | Контрольована інструкція ремонту, авторизація, записи до/після |
| Утилізація та надлишкові матеріали | Як знищуються або повертаються запрограмовані пристрої, несправні плати, етикетки та чутлива пам’ять? | Запис про утилізацію та метод, погоджений замовником |
| Випуск | Чи кожен відвантажений пристрій має затверджене мікропрограмне забезпечення, конфігурацію, стан безпеки та результат тестування? | Запис випуску партії або пристрою зі статусом винятків |
Не передавайте виробничі ключі підпису лише тому, що контрактному виробнику потрібно завантажити мікропрограмне забезпечення. Архітектура безпеки має мінімізувати відкриті повноваження, розділяти ролі та чітко визначати кожен необхідний привілей. Використовуйте послуги підтримки PCBA і тестування та контроль якості, щоб визначити передачу виробничих процесів, а потім підтвердьте конкретні заходи контролю в комерційній пропозиції та угоді.
Процес оцінювання вразливостей
1. Планування оцінювання
Визначте цільові апаратні та програмні версії, тестові пристрої, стани продукту, облікові записи, інтерфейси, допоміжні сервіси, заборонені методи, правила роботи з даними, формат звітування та терміни усунення. Зафіксуйте тестовану конфігурацію, щоб результати можна було відтворити.
2. Перевірка архітектури та проєктних даних
Перевірте блок-схеми, потоки даних, схеми, файли PCB, BOM, архітектуру процесора та пам’яті, ланцюг завантаження, дизайн оновлень, стратегію налагодження, життєвий цикл ключів, виробничий процес і вимоги безпеки. Така перевірка часто виявляє відсутні засоби захисту ще до початку лабораторних випробувань.
3. Створення інвентаризації поверхні атаки
Перелічіть фізичні, внутрішні, дротові, бездротові, програмні, хмарні, оновлювальні, відновлювальні та виробничі інтерфейси. Зафіксуйте, які з них активні в кожному стані життєвого циклу і які засоби автентифікації, авторизації, цілісності, конфіденційності та журналювання застосовуються.
4. Проведення авторизованого технічного тестування
Використовуйте ризик-орієнтовану комбінацію перевірки конфігурації, тестування інтерфейсів, аналізу мікропрограмного забезпечення, перевірки оновлень і відновлення, перевірки облікових даних, комунікаційних тестів, перевірки фізичного доступу та аналізу очікуваних аварійних станів. Зберігайте достатньо доказів для відтворення проблеми без публікації конфіденційних деталей експлуатації.
5. Сортування та усунення проблем
Для кожної знахідки зафіксуйте уражений актив, передумови, рівень доступу, вплив, уражені версії, докази, рекомендований захід, відповідального, дату виконання та компенсувальні заходи. Усуньте першопричину в архітектурі, апаратному забезпеченні, мікропрограмному забезпеченні, підготовці або експлуатації, а не просто приховуйте виявлений інтерфейс.
6. Повторне тестування та випуск
Повторно перевірте виправлений шлях і суміжні стани, а потім оновіть моделі загроз, вимоги, виробничі інструкції, сервісні процедури та регресійні тести. Випуск має показувати, які проблеми закриті, прийняті, зменшені або відкладені уповноваженими відповідальними особами.
Як слід визначати пріоритет апаратних вразливостей?
CVSS може допомогти описувати програмні вразливості, але рішення щодо апаратного та вбудованого пристрою також залежать від фізичного доступу, масштабу парку, можливості ремонту, впливу на безпеку та виробничого середовища.
| Фактор | Питання для сортування |
|---|---|
| Доступ | Чи є експлуатація віддаленою, локальною, через радіоканал, тимчасовий фізичний доступ, постійний фізичний доступ або ланцюг постачання? |
| Передумови | Чи потрібні облікові дані, привілейований стан, відкриття корпусу, спеціальне обладнання або певний стан продукту? |
| Вплив | Чи може проблема розкрити секрети, встановити несанкціонований код, змінити критичну поведінку, зберігатися після скидання/оновлення або вимкнути відновлення? |
| Масштаб | Чи стосується проблема одного пристрою, партії, набору ключів, версії мікропрограми або всього парку? |
| Виявлення | Чи виявить власник, пристрій, сервіс або виробнича система експлуатацію чи зміну конфігурації? |
| Відновлення | Чи можна безпечно оновити, скинути, змінити ключі, відремонтувати або відкликати пристрій? Чи зберігається довіра? |
| Надійність доказів | Чи є результат підтвердженим шляхом експлуатації, недоліком конструкції, неперевіреним припущенням конфігурації або теоретичною проблемою? |
Фізично складна атака все одно може бути критичною, якщо один отриманий секрет компрометує ціле сімейство продуктів. Віддалена проблема може мати нижчий пріоритет, якщо вона не впливає на чутливі активи та надійно локалізована. Критичність має відповідати реальній моделі продукту.
Поширені помилки під час оцінювання
| Слабка практика | Чому це не працює | Кращий підхід |
|---|---|---|
| Розглядати DFM як оцінювання безпеки | Виробничість не перевіряє авторизацію, цілісність мікропрограмного забезпечення, облікові дані або оновлення | Проводити DFM і перевірку кібербезпеки як окремі узгоджені етапи |
| Сканувати лише мережеві сервіси | Фізичні інтерфейси, мікропрограма, пам’ять, відновлення та підготовка залишаються неперевіреними | Використовувати модель пристрою, що охоплює апаратне забезпечення, мікропрограму, комунікації, застосунки та експлуатацію |
| Вважати, що захищений елемент вирішує всі проблеми | Інтеграція, підготовка, політика доступу, оновлення та життєвий цикл ключів можуть залишатися вразливими | Перевіряти повний ланцюг довіри та експлуатаційний життєвий цикл |
| Вимикати налагодження лише в документації | Виробнича конфігурація або альтернативні стани життєвого циклу можуть залишати доступ відкритим | Тестувати реальний виробничий стан і шляхи сервісу/відновлення |
| Використовувати спільні облікові дані або ключі | Один витік може вплинути на багато пристроїв і ускладнити відкликання | Використовувати відповідну унікальність, ротацію, відкликання та аудит |
| Звітувати без повторного тестування | Команда не може довести ефективність виправлення або відсутність регресії | Вимагати докази закриття та цільові регресійні тести |
| Широко публікувати чутливі деталі експлуатації | Сам звіт стає ризиком | Обмежити технічні докази авторизованими отримувачами та створити окремий управлінський звіт |
Чекліст RFQ для оцінювання вразливостей PCB
Контекст продукту та загроз
- Призначення пристрою, користувачі, середовище застосування, вплив на безпеку, підключення та очікуваний фізичний доступ
- Активи, межі довіри, модель атакувальника, стани продукту, масштаб парку та очікування щодо відновлення
- Вимоги замовника, нормативні, галузеві, приватності та кібербезпеки з відповідними редакціями
Технічний пакет
- Блок-схема, діаграма потоків даних, схеми, дані PCB, BOM, архітектура процесора/пам’яті та інвентаризація інтерфейсів
- Версії мікропрограмного забезпечення та завантажувача, дизайн оновлення/відновлення, налагодження/сервісу, конфігурація та сторонні компоненти
- Корпус, роз’єми, тестові точки, шляхи програмування, захищені елементи, зовнішня пам’ять і дизайн зберігання ключів
Виробництво та життєвий цикл
- Процес програмування та підготовки, затверджені образи, ідентифікатори, сертифікати, ключі, серіалізація, журнали та межі доступу
- Перше завантаження, нормальна робота, сервіс, ремонт, доопрацювання, скидання до заводських параметрів, передача власності, виведення з експлуатації та утилізація
- Постачання компонентів, контроль змін, отримання інформації про вразливості, період підтримки ПЗ, політика оновлень і відповідальність за реагування на інциденти
Оцінювання та результати
- Авторизовані методи тестування, заборонені техніки, тестові пристрої, облікові записи, лабораторні обмеження, робота з даними та правила розкриття
- Формат результатів, метод визначення критичності, докази відтворення, рекомендації з усунення, обсяг повторного тестування та управлінський звіт
- Відповідність стандартам, матриця трасування, прийняття відкритих ризиків і докази випуску
Використовуйте сторінку APTPCB про 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 відповідає за виготовлення відповідно до затверджених даних і договірних засобів контролю. Власник продукту зберігає відповідальність за моделювання загроз, архітектуру безпеки, програмне забезпечення, повноваження щодо ключів, керування вразливостями, нормативну відповідність, системну валідацію та реагування у польових умовах.
FAQ
Чи є оцінювання вразливостей PCB тим самим, що й DFM-перевірка?
Ні. DFM перевіряє, чи може плата бути виготовлена за запропонованою конструкцією та процесом. Оцінювання вразливостей аналізує, чи створюють апаратне забезпечення, мікропрограма, інтерфейси, облікові дані, оновлення, підготовка та експлуатаційні стани вразливості безпеки.
Чи можна виконати тест проникнення для голої PCB?
Голу PCB можна перевірити на особливості конструкції та виробничі аномалії, але змістовне тестування проникнення зазвичай потребує зібраного пристрою, виробничої мікропрограми, корпусу, інтерфейсів, облікових даних і допоміжних сервісів. Межа безпеки більша за креслення плати.
Які інтерфейси потрібно перевіряти у вбудованому пристрої?
Потрібно інвентаризувати всі фізичні, внутрішні, дротові, бездротові, налагоджувальні, програмувальні, тестові, сервісні, відновлювальні, змінні носії, сенсорні та виконавчі інтерфейси. Перевірте, які з них активні у виробничому, нормальному, сервісному, оновлювальному, відновлювальному та виведеному з експлуатації станах.
Чи робить безпечне завантаження пристрій безпечним?
Ні. Безпечне завантаження може захищати ланцюг довіри під час запуску, але безпека також залежить від захисту ключів, авторизації оновлень, політики проти відкату, відновлення, контролю налагодження, програмного забезпечення під час роботи, облікових даних, комунікацій, підготовки та реагування на інциденти.
Чи потрібно видаляти налагоджувальні порти з виробничих PCB?
Це залежить від конкретного продукту. Видалення роз’єму може зменшити поверхню атаки, але не вимикає сам інтерфейс. Виробничий життєвий цикл, автентифікація, авторизований сервіс, відновлення та перевірка після програмування мають проєктуватися й тестуватися разом.
Як часто потрібно повторювати оцінювання вразливостей апаратного забезпечення?
Повторюйте або оновлюйте його при зміні апаратного забезпечення, мікропрограмного забезпечення, завантажувачів, компонентів, постачальників, підготовки, хмарних сервісів, інтерфейсів, припущень щодо загроз, нормативів або виробничих майданчиків — а також коли нові вразливості впливають на включені компоненти чи програмне забезпечення.
Які докази має містити звіт з оцінювання безпеки?
Він має містити протестовану конфігурацію, обсяг, припущення, методи, уражені активи та версії, передумови, вплив, відтворювані докази, обґрунтування критичності, усунення, відповідального, статус і результат повторного тестування. Чутливі технічні деталі повинні мати контрольований доступ.
Запит на перевірку безпечного виробництва
Надішліть випущений пакет апаратного забезпечення, область програмування та підготовки, затверджені ідентифікатори мікропрограмного забезпечення, вимоги до простежуваності, правила роботи з конфіденційними даними безпеки, кількість і необхідні докази. APTPCB може перевірити недоліки передачі виробництва та PCBA; тестування кібербезпеки продукту залишається залежним від погодженого обсягу та відповідального органу безпеки.