When Hardware Gets Pwned Mechanics Of Detection, Response And Recovery
summary
A firmware implant hides in an enterprise switch, deployed to 200 branch offices, survives factory reset and stays dormant until a researcher finds UART/JTAG artifacts or a PoC video. Detection requires purpose-built runtime signals — power, fan and vibration telemetry or correlation in an emulated lab — not checklist audits. Response combines triage, supplier engagement, firmware or hardware respin, stop‑ship decisions and sometimes rolling trucks for physical replacement; proof‑of‑concept and reproducible lab replication determine scope and urgency.
AI-written summary · about
chapters (14)
- 0:00Introduction to hardware compromise
- 1:19Firmware persistence detection challenge
- 5:57Builder perspective on supply chain implants
- 9:31Hardware security tools and gaps
- 11:35Assessor workflow for hardware testing
- 17:56Reporting hardware findings to manufacturers
- 20:24Handling hardware security findings
- 22:32Incident response for hardware compromise
- 29:16Remediation limits for hardware in field
- 32:05Trust erosion after hardware compromise
- 37:23Hardware detection investment and architecture
- 40:59Future-proofing hardware for detection
- 43:26End user capability for hardware compromise
- 44:51Call to action for researchers
related talks
21mIndustrial IoT security issues and countermeasures
52mAnatomy of a Vulnerability Response - A View from the Inside
27mProtecting Data In-Use from Firmware and Physical Attacks
51mFirmware Cartography: Charting the Course for Modern Server Compromise
24mIf They Can Touch It, They Own It: The Stories We Tell...
07mEntrevista
40mWhen hardware attacks scale
41mUnique Challenges Of Security Programs For Hardware/IoT Makers