В сегодняшней быстро развивающейся цифровой среде угрозы для целостности программного и микропрограммного обеспечения представляют собой все большую проблему для организаций, стремящихся защитить свои ИТ-активы и критическую инфраструктуру. В условиях роста атак на цепочку поставок микропрограмм и программного обеспечения контроль SA-10(1): Проверка целостности программного/микропрограммного обеспечения из системы безопасности NIST SP 800-53 становится важным дополнением для специалистов по кибербезопасности и ИТ-лидеров. Этот подробный пост в блоге разъяснит SA-10(1), охватит практические методы проверки целостности микропрограмм и представит практические примеры кода для реальной реализации, ориентированные на аудиторию от начинающих до продвинутых пользователей.
- Что такое SA-10(1) – Проверка целостности программного/микропрограммного обеспечения?
- Почему важна целостность микропрограммного и программного обеспечения?
- Как злоумышленники нацеливаются на целостность микропрограммного обеспечения
- Требования и лучшие практики SA-10(1)
- Методы и стратегии проверки целостности микропрограммного обеспечения
- Примеры использования в реальных условиях: Обнаружение несанкционированных изменений
- Реализация проверки целостности микропрограммного обеспечения: Образцы кода
- Продвинутые подходы к целостности микропрограммного обеспечения
- Проблемы и ограничения
- Заключение
- Ссылки
SA-10(1): Проверка целостности программного/микропрограммного обеспечения — это усиление контроля, описанное в Специальной публикации NIST 800-53, Редакция 4. Цель состоит в том, чтобы обеспечить способность организаций обнаруживать несанкционированные изменения — например, вставку, модификацию или удаление кода — в компонентах программного и микропрограммного обеспечения на протяжении всего их жизненного цикла.
Официальный язык контроля (источник):
"Организация использует инструменты для обнаружения несанкционированных изменений в компонентах программного и микропрограммного обеспечения."
Организации реализуют этот контроль, используя:
- Инструменты или методы для проверки целостности программного обеспечения до и после его развертывания.
- Обеспечение аутентичности и немодифицированности микропрограмм, а также их происхождения из надежного источника перед установкой или выполнением.
- Периодическая повторная оценка активов для выявления неожиданных изменений или уязвимостей.
- Устойчивость: Микропрограммы находятся ниже уровня операционной системы и могут обходить обнаружение стандартными инструментами безопасности.
- Привилегии: Злокачественное микропрограммное обеспечение обычно работает с повышенными привилегиями (корневой/системный уровень).
- Атаки на цепочку поставок: Злоумышленники могут компрометировать продукты до того, как они достигнут пользователей, как это было в случае с атакой на SolarWinds.
- Скрытность: Измененные микропрограммы могут пережить стирание системы или переустановку ОС, обеспечивая несанкционированный и устойчивый доступ.
Поддержание целостности программного и микропрограммного обеспечения важно для:
- Предотвращения установки вредоносного или устаревшего кода.
- Проведения анализа причин инцидентов и реагирования на них.
- Соответствия нормативным и отраслевым стандартам (таким как FISMA, FedRAMP, ISO/IEC 27001).
Некоторые распространенные стратегии атак на микропрограммное/программное обеспечение:
- Корневые комплекты микропрограмм: Злоумышленники внедряют зловредный код на уровне UEFI/BIOS (например, LoJax).
- Зловредные обновления: Враги компрометируют сервер обновлений или процесс доставки, чтобы вставить несанкционированный код.
- Отравление цепи поставок: Код изменяется во время производства или распространения (например, компрометированные аппаратные устройства).
- Уязвимости в механизмах обновления: Эксплуатация слабо проверяемых или неподписанных процессов обновления микропрограмм.
Задняя дверь была внедрена в широко используемое серверное программное обеспечение через поврежденные обновления и попала в тысячи организаций до выявления.
Реализация SA-10(1) включает несколько ключевых шагов и стратегий:
- Базовые данные и инвентаризация: Поддерживайте точный список и базовую версию всего программного и микропрограммного обеспечения.
- Проверка перед развертыванием: Всегда проверяйте хеш/цифровую подпись и источник обновляемых изображений перед установкой.
- Непрерывный мониторинг: Регулярно сканируйте системы на наличие несанкционированных изменений.
- Автоматизированные инструменты обнаружения: Используйте как пользовательские, так и коммерческие продукты для постоянных проверок целостности.
- Регистрация и предупреждение: Регистрируйте сбои целостности и генерируйте оповещения для реагирования на инциденты.
- Проверка поставщиков и цепочек поставок: Убедитесь, что поставщики предоставляют подписанные и проверяемые обновления микропрограммного/программного обеспечения.
Проверка целостности микропрограммного обеспечения — это процесс проверки того, что микропрограмма (и аналогично программное обеспечение) является аутентичной, немодифицированной и надежной перед установкой или выполнением. (источник)
- MD5, SHA-1, SHA-256 и SHA-3 являются распространенными криптографическими хеш-функциями.
- Хеширование содержимого микропрограммы и сравнение с известным хорошим хешем (из надежного источника) позволяет обнаружить модификации.
- Образы микропрограмм могут быть подписаны с использованием приватного ключа поставщика.
- Получатель проверяет подпись, используя публичный ключ поставщика, обеспечивая аутентичность и целостность.
- Распространенные стандарты: RSA, DSA и подписи на базе ECC.
- Многие современные устройства выполняют криптографическую проверку в процессе загрузки (например, Intel Boot Guard, Windows Secure Boot).
- Если проверка не проходит, система остановится или откажет в выполнении.
- Хеши/подписи, предоставляемые поставщиками.
- Аутентифицированные и зашифрованные каналы доставки микропрограмм.
- Аппаратные корни доверия (например, TPM).
Поставщики могут встроить проверку целостности в устройства:
- UEFI Secure Boot (ПК): Проверка подписей загрузчиков перед загрузкой.
- Cisco IOS Secure Boot (сетевые устройства): Проверка системных изображений при запуске.
- Apple Secure Enclave: Обеспечение выполнения только проверенного кода на аппаратном обеспечении Apple.
- Binwalk: Анализирует, извлекает и проверяет бинарные изображения микропрограмм.
- firmware-utils: Наборы инструментов для сборки/проверки встроенных микропрограмм.
- fwupd: Утилита для управления прошивкой устройств на Linux, проверяющая подписи поставщиков.
- Tripwire/AIDE/OSSEC: Мониторинг целостности системных файлов (не напрямую микропрограмм, но аналогичные концепции хеширования/аудита).
- Утилиты, предоставляемые поставщиками: Многие поставщики предлагают CLI для проверки целостности микропрограмм или BIOS.
- ИТ-безопасность предприятий: Мониторинг серверов и коммутаторов на наличие несанкционированных изменений BIOS/прошивки после цикла обновлений.
- Станции зарядки электромобилей: Проверка аутентичности программного обеспечения зарядных устройств для предотвращения саботажа (пример).
- Развертывание IoT: Проверка на несанкционированные изменения из-за уязвимостей физического доступа.
- Безопасность SCADA / ICS: Обнаружение измененного программного обеспечения ПЛК для предотвращения манипуляции операциями.
Этот раздел содержит практические команды и фрагменты кода для проверки целостности на различных уровнях: от базовых проверок хеша до проверки цифровой подписи и скриптов для автоматизации.
Предположим, вы загрузили образ микропрограммы, предоставленный поставщиком (router-firmware.bin), и на официальном сайте предоставляется хеш SHA-256 для проверки.
sha256sum router-firmware.bin
Ожидаемое выходное значение:
123456789abcdef... router-firmware.bin
Сравните этот результат с хешем, предоставленным поставщиком. Несоответствие указывает на возможное вмешательство или ошибку передачи.
Предположим, что хеш поставщика хранится в vendor.hash:
# vendor.hash содержит: 123456789abcdef... router-firmware.bin
sha256sum -c vendor.hash
Выходное значение:
router-firmware.bin: OK
Проверьте все образы микропрограмм в формате .bin в каталоге и укажите несоответствия:
#!/bin/bash
for file in *.bin; do
calc_hash=$(sha256sum "$file" | awk '{print $1}')
vendor_hash=$(grep "$file" hashes.txt | awk '{print $1}')
if [[ "$calc_hash" != "$vendor_hash" ]]; then
echo "[ALERT] Несоответствие хеша: $file"
else
echo "[OK] $file проверено."
fi
done
Если поставщик предоставляет подписанный образ прошивки (firmware.signed) вместе с их открытым ключом (vendor_public.pem):
openssl dgst -sha256 -verify vendor_public.pem -signature firmware.sig firmware.bin
Ожидаемое выходное значение:
Verified OK
Автоматически получайте и проверяйте хеши для большого количества устройств:
import hashlib
def verify_firmware(file_path, known_hash):
sha256 = hashlib.sha256()
with open(file_path, 'rb') as f:
for chunk in iter(lambda: f.read(4096), b""):
sha256.update(chunk)
calc_hash = sha256.hexdigest()
return calc_hash == known_hash
# Пример использования
if verify_firmware("router-firmware.bin", "123456789abcdef..."):
print("Целостность прошивки подтверждена!")
else:
print("ВНИМАНИЕ: Несоответствие хеша прошивки!")
Binwalk обычно используется для проверки содержимого микропрограмм на наличие аномалий, например, неожиданных файлов:
binwalk firmware.bin
Пример вывода:
ДЕСЯТИЧНОЕ ШЕСТНАДЦАТЕРИЧНОЕ ОПИСАНИЕ
--------------------------------------------------------------------------------
0 0x0 Файл прошивки (полезный заголовок здесь)
1024 0x400 Сжатые данные GZIP, был "file.bin", из Unix
...
Проверьте извлеченные файлы на наличие неожидаемого содержимого.
for fw in *.bin; do
binwalk -e "$fw"
done
- Доверенные модули платформы (TPM) и Аппаратные модули безопасности (HSM) могут хранить известные хорошие значения хеша и выполнять проверку перед загрузкой системы.
- Устройства могут проверять микропрограммы с помощью цепочек сертификатов, основанных на PKI, обеспечивая выполнение только подписанных изображений от поставщика.
- Системы могут сообщать (через измеренную загрузку) текущие хеши микропрограмм/программного обеспечения на удаленный сервер, который сравнивает с ожидаемой базовой линией.
- Инструменты управления информацией и событиями безопасности (SIEM) могут собирать и анализировать выходные данные сканирования целостности для мониторинга на уровне всего флота.
- Интеграция верификации в конвейеры DevSecOps гарантирует, что в продукцию попадают только проверенные изображения.
- Нет единого метода, подходящего для всех типов устройств. Некоторые поставщики не поддерживают проверку подписей или хешей для их микропрограмм.
- Не все инструменты с открытым исходным кодом могут анализировать проприетарные блоки микропрограмм.
- Многие устройства критической инфраструктуры не поддерживают современные средства проверки целостности, требующие компенсирующих средств (сегментация сети, физическая безопасность).
- Многовендорные части означают, что проверка "цепочки доверия" на каждом этапе сложна.
- Злоумышленники могут нацелиться на поставщиков, у которых отсутствуют надежные средства контроля целостности.
- Обновления, патчи или легитимные изменения могут вызывать аварийные сигналы, если не управлять ими осторожно.
- Балансировка безопасности с операционной непрерывностью — это вызов.
SA-10(1): Проверка целостности программного/микропрограммного обеспечения — это необходимый контроль, который обеспечивает современную кибербезопасность, защищая от все более сложных атак на цепочки поставок и микропрограммы. Используя хеширование, цифровые подписи, автоматизированный мониторинг и лучшие практики, организации любого размера могут внедрять надежные проверки целостности на всех программных и микропрограммных активах.
Для начинающих простая проверка хешей и подписей может стать мощным первым шагом. Продвинутые пользователи могут использовать автоматизированные инструменты, удаленную проверку подлинности и аппаратные корни доверия, чтобы масштабировать защиту в масштабе всей организации. Несмотря на существующие проблемы, соблюдение принципов SA-10(1) значительно снижает риск атак, обеспечивая доверие к критически важным системам.
- NIST SP 800-53 Rev 4: SA-10(1) – Проверка целостности программного/микропрограммного обеспечения
- Проверка целостности микропрограмм – Глоссарий Elinta Charge
- Проверка целостности микропрограмм – r/cybersecurity
- Семейство контрольных средств NIST SP 800-53 – Приобретение систем и услуг
- Инструмент анализа микропрограмм Binwalk
- fwupd Linux Vendor Утилита обновления прошивки
- UEFI Secure Boot
- Intel Resilience платформенных микропрограмм
- Уведомления CISA о компрометации цепочки поставок
- Tripwire | AIDE
Оптимизируйте подходы к обеспечению безопасности вашей организации — внедрите SA-10(1) и убедитесь, что каждая строка кода и каждый байт прошивки соответствуют вашим ожиданиям, и ничего больше!
