Press Release
Last Updated on January 15, 2024
The OWASP Foundation is a globally respected source of guidance on web application security. Many cybersecurity practitioners will be familiar with OWASP’s well-known Top 10 and Application Security Verification Standard (ASVS) documents, among its lengthy list of contributions to our field.
No strangers to leading from the front, the folks at OWASP have recently developed much-needed guidance in the area of Internet of Things (IoT) security, with their new IoT Security Verification Standard (ISVS).
To unbox the new ISVS and discover what it covers and how it’s intended to be used, we went straight to the source: Aaron Guzman, OWASP IoT project lead and product security lead for Cisco Meraki, was our guest on a recent episode of The Virtual CISO Podcast.
To kick off the discussion on how the ISVS is organized, podcast host John Verry, Pivot Point Security’s CISO and Managing Partner, does his best to share a graphic from the document with our podcast video viewers.
“I really like this graphic because when I first opened up the ISVS I was trying to find my way in and understand the thought process here… And I thought this was a really cool way to look at it,” relates John. “You’ve got these 5 sections, and within them you have these 18 specific areas of concentration. And then within that you’ve got 124 different requirements across those 18 different areas.”
“So the way you look at this image is bottom-up,” Aaron explains. “And even from when a product comes into what they call NPI (New Product Introduction)… You start with product requirement documents (PRDs), which define all the fun stuff that that device or that product is going to do. For us, you start reviewing the hardware PRDs first. Then there’s also software feature PRDs—and that’s where you can put some of the more drill-down details of what the product should be following from a requirements standpoint.”
Aaron continues: “That’s where the Software Platform (to the left) which is everything after … the secure boot chain has finished… Everything to the User Space Applications on top. Then Software Updates and then we have the Kernel Space as well. So that’s the way product teams are usually structured and who’s responsible for that particular area are platform teams. So we wanted to make sure that we communicate [in terms of] how teams actually work.
“And then I obviously have that insider knowledge – I’m fortunate to have that experience and have worked in different product companies. So being able to relay that to the proper team from the Software Platform and then going over to the Communication and User Space applications—that’s usually like the higher-level product teams who are working on different types of features.
“And they’ve got different subcategories in here within Communication, User Space Applications; and, of course, there’s general things that apply to any type of application or environment or device. We wanted to make sure that we covered what is particular and what are the most common use case for IoT and embedded devices.
“The approach with some of these is, there are device-level or product-level requirements, and then there’s ecosystem-level requirements. As you see at the top there with Application Ecosystem Design, Secure Development, Supply Chain… And Supply Chain will feed off of what the OWASP SCVS has done, while Secure Development feeds off of the OWASP ASVS. Even in our control objectives at the top of each section we make sure to note and reference our sister projects.
“So it’s pretty drill-down as far as from a device perspective. But also the ecosystem, right? Because IoT is usually ‘systems within systems.’ So it can get as complex as you want. And everyone has their perspective on the category of IoT; connected vehicles, for example. They have their own complexities in the way they interact with each other.
“We try to hit the breadth of all of IoT from that perspective. But there are particular things like, for example, automotive, where it’s a little bit difficult to give that specific guidance and best practices where it wouldn’t really apply as much to the rest of the categories of IoT. So it could be too niche.
“Similarly, things like log integrity and some kinds of forensic based controls were also deemed ‘out of scope.’ Part of the reason why OWASP is the platform here that we’re using [for this guidance] is everything is software—from hardware to wireless communication to Bluetooth…
Everything’s a library, everything’s a file. All the chips, everything is software. And it’s going to continue to be software,”
Aaron observes.
If you’re interested in IoT security, this podcast episode with Aaron Guzman will be well worth your time.
To hear the whole show, click here. If you don’t use Apple Podcasts, you can check out all our cybersecurity podcast episodes here.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
