Last Updated on March 27, 2021
[et_pb_section fb_built=”1″ _builder_version=”4.9.2″ _module_preset=”default”][et_pb_row _builder_version=”4.9.2″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.9.2″ _module_preset=”default”][et_pb_text _builder_version=”4.9.2″ _module_preset=”default”]
Anybody who is involved with securing or validating Internet of Things (IoT) solutions knows that they often involve a web of connections that can be (to put it mildly) tricky to navigate. How do you approach testing a complex “ecosystem” of physical devices, embedded software, cloud services, communication protocols, mobile code, and more?
Looking to address the requirements of IoT security stakeholders from designers to product managers to developers to testers, the OWASP Foundation, a leading source of web application security guidance, is about to release its new Internet of Things (IoT) Security Verification Standard (ISVS).
To learn how the new OSWASP ISVS addresses IoT testing at the ecosystem level, we spoke with Aaron Guzman, OWASP IoT project lead and product security lead at Cisco Meraki, on a recent episode of The Virtual CISO Podcast.
The ISVS therefore specifies secure requirements for embedded applications in the IoT ecosystem in which they reside, while referring to existing industry-accepted standards as much as possible.
How applicable is the ISVS to validating security at the ecosystem level? And how does the ISVS define ecosystem in the first place? Podcast host John Verry, Pivot Point Security’s CISO and Managing Partner, points out, “There was a line in the document that I liked: The ISVS therefore specifies secure requirements for embedded applications in the IoT ecosystem in which they reside, while referring to existing industry-accepted standards as much as possible.”
“When you look at some of the [ISVS] guidance, you’ll see machine-to-machine, and then you’ll see the wireless protocols,” Aaron explains. “cBut we want to keep it simple, as concise as we can, and clear. There’s a focus on device- or product-level down to the firmware. And we piggyback on ASVS [the OWASP Application Security Verification Standard] and MASVS [the OWASP Mobile Application Security Verification Standard] where we can; and NIST for Bluetooth and the cryptography.”
“I think what we’ll need to do at some point is provide more visuals; some more graphics that can help with where we draw the line and the boundary [on IoT ecosystems]. We do include a basic diagram to give you a better idea of the scope that we’re talking about. But more of how it looks in a real environment, from a data flow diagram perspective. This is something that we did with the Cloud Security Alliance IoT Controls Framework to be able to help with that context.”
John interprets the existing “ecosystem” graphic in a real-world context: “So we’ve got the device in and of itself. That device is talking to other devices in the local environment. Those devices may or may not serve local APIs, local web services. I might have a mobile application that’s being used to configure or operate said devices. That mobile device might be consuming APIs or services off of the local device, or it might be talking to the cloud.”
“Then you’ve got the web app with the cloud, the APIs,” continues John. “Then those APIs may be exposed to partner ecosystems. If it’s a smart speaker, you’ve got Spotify and Pandora and people of that nature.”
“What would be cool to see is OWASP’s vision of how to understand risk and how to guide folks developing and testing,” John suggests. “The MASVS for the mobile stuff, the OWASP ASVS Level 2 for the cloud APIs and the web infrastructure if that doesn’t just consume those endpoints. Testing of the local web services through conventional network or OWASP Top 10 maybe, because that’s a lower exposure, lower threat surface. … That’s how we’re piecing it together.”
If you’re looking for support with your IoT security and testing efforts, this podcast with Aaron Guzman on the OWASP ISVS will be well worth your time.