AI
The Missing Piece in IoT Security Testing
IoT pentests historically return a list of findings. No visibility into how tests ran, no risk rationale, no way to repeat the assessment. Aaron Guzman and co-lead Luca started the OWASP IoT Security Testing Guide to fill that gap. OWASP had the Web Testing Guide and Mobile Testing Guide, but nothing for full device pentesting. Existing books and publications existed but weren’t operationalizable by an internal pentest team or a product certification lab.
Four Physical and Four Authorization Access Levels
The ISTG defines four physical access levels. PA1 is remote access over the internet. PA2 is local network access. PA3 is non-invasive physical access (you can touch the device but not open it). PA4 is invasive access: opening the enclosure, attaching to internal interfaces like memory or CPU, and debugging. Four authorization levels run parallel: unauthorized (no account), low privilege (standard user), high privilege (admin-level configuration access), and manufacturing level (developer debug mode with root access and potentially source code).
Test Cases Across Eight Device Interfaces
Eight device interfaces each have their own test cases. The interfaces run from firmware and data exchange services to processing units, internal memory connections, physical interfaces, wireless, and user interfaces (web and API). Each test case specifies the objective, a risk summary, the required physical and authorization access level, and remediation guidance. Categories span information gathering, authorization testing, configuration and patch management, secrets, cryptography weaknesses, and input validation. Specific testing techniques stay up to the tester.
Scoping a Test: Commercial Camera vs. Smart Home Camera
A mounted commercial security camera in a hotel illustrates PA2 with no user account. The tester can only reach it over LAN or WAN, unauthorized. Applicable test cases shrink to data exchange services (network sniffing), wireless interfaces, and user interfaces. A consumer smart home camera is the opposite: physical access is available, the enclosure can be opened (PA4), and a standard user account exists (low privilege). The goal becomes escalating from that user account to manufacturing debug mode, since every manufacturer ships a debug mode even on devices with secure boot.
Roadmap: Modular Expansions and Industry Adoption
The guide ships in Markdown, Excel, and PDF. The current version covers firmware installation and OTA update mechanisms. Planned modular expansions include USB, Ethernet, Wi-Fi, Bluetooth, Zigbee, and Z-Wave. Priority follows community demand. The OWASP Web Testing Guide has adoption from CREST, NIST, BSI, ADA for Google, and FirstNet (ATT’s First Responder certification program). The ISTG targets that same adoption track. Contributions are open to beginners and experienced practitioners, with discussions on GitHub and the OWASP ISTG Slack channel.
Q&A
Does the guide include technique guidance beyond the test case objectives? The guide references existing OWASP projects and external publications for technique guidance, keeping the how flexible across different hardware architectures (x86, ARM, and others). ▶ Watch (22:18)
Can analyzing a physically inaccessible device’s firmware still reveal network-reachable vulnerabilities? Yes, pulling firmware is often an engagement goal, but if a tester only has an IP address, work is limited to network-based information gathering. ▶ Watch (23:47)
Notable Quotes
this is really like the meat and potatoes of of of the guide Aaron Guzman · ▶ Watch (9:52)
every manufacturer has a debug mode uh even if you have secure boot Aaron Guzman · ▶ Watch (17:59)
that’s a thing to kind of future proof the guide and not get too prescriptive Aaron Guzman · ▶ Watch (22:44)
Key Takeaways
- IoT pentests without a structured methodology return findings with no risk rationale and no repeatability.
- The ISTG scopes engagements through four physical access levels (PA1-PA4) and four authorization levels.
- Eight device interfaces each carry dedicated test cases covering authorization, patch management, secrets, and input validation.
About the Speaker(s)
Aaron Guzman is Head of Trust Assurance at Cisco Meraki, protecting millions of cloud-managed networks and end-users. His team spans product security, firmware, hardware, offensive security, cloud, web, and API. He extends his work to the community through leadership in open-source projects, including co-leading the OWASP IoT Security Testing Guide.