Last Updated on March 25, 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”]
As a cybersecurity professional, you’ve probably heard of the nonprofit OWASP Foundation, a prominent authority on application security planet wide. OWASP is well-known for its Top 10 Vulnerabilities and Application Security Verification Standard (ASVS), to name just two of the many documents, standards and other guidance the organization has put out.
One of OWASP’s most important recent efforts is its Internet of Things (IoT) Security Verification Standard (ISVS). What does this much-needed document provide, who is it intended for, and how is it meant to be applied?
Among its many strengths, the ISVS incorporates a risk level-based approach so you can tailor its controls to your needs. Aaron describes: “Level 1 is software only protections against attacks, [where you] don’t really require physical access to a device. Level 1 is really like a baseline; it’s where you start. We have some examples on the project page to give some context. Like smart light bulbs and other simple devices that may have minimal feature sets. Or some basic consumer off-the-shelf products where there’s a basic level of requirements that a partner or third-party defines for them and that’s all they want to adhere to.”
“But Level 2 provides protection against both software and hardware attacks,” indicates Aaron. “Examples are alarm systems, smart cameras and medical devices. While Level 3 is to provide requirements for devices that should be [secured] at all costs, and we think of these as hardware crypto wallets, vehicles, medical implants, and so forth. It’s really the highest level of security. Maybe there are direct safety concerns, or monetary concerns as well.”
“[Level 3 devices] should provide a high level of assurance and trustworthiness, meaning the device or product or vehicle should always function as it’s designed,” continues Aaron. “Even if it’s being attacked or even if it’s trying to be modified, there are controls in place to hinder those types of attacks. Reverse engineering and tampering are some of them, although we didn’t go too far into that rabbit hole. Because you can really go deep as far as the layers you put onto resiliency, although it’s a topic that we’re considering for a future version…”
“You really have to be doing the basics, the fundamentals first, but definitely keep the resiliency part, the tamper protections in mind,” underscores Aaron. “But if the basics aren’t done, all the work you’ve put in for the resiliency areas, attestation and things like that… and it’s also product dependent and even chip dependent. That’s the complexity with embedded devices. You’re usually reliant on a partner of some sort, and that could be a semiconductor partner. That could be original design manufacturer or a contract manufacturer, just a supply chain and how things are sourced. You’re sometimes constrained by those choices that you may not even have an opportunity to give feedback, and maybe security teams aren’t even looped into those discussions.”
To sum up, the Level 1 protections relate to connectivity/remote access only. Level 2 is intended to protect a device not only from web-based attacks, but also from physical tampering. Level 3 should protect from expert physical hacking like manipulating chips or reverse engineering components.
John Verry, podcast host and Pivot Point Security’s CISO and Managing Partner, offers a real-world example: “There’s a group of devices we just beat up pretty badly [as penetration testers], and they left holes in the case to get to the debug SWD. Because from their perspective it was, like, ‘Okay, that way we can troubleshoot something if we have to.’ But [the designers] didn’t fully understand the implication of making those holes in the case. We didn’t even have to open up the case to do what we needed to do.”
“The minute we get to a point where a script kiddie can buy a tool and maybe attack a device, we want to do everything we can to prevent that from happening, right?” discerns John.
Need to secure IoT devices or ecosystems? You’ll definitely want to check out the ISVS, along with this podcast with Aaron Guzman.