Discovery: Step 1 of Connected Device Security

Cybersecurity, like the cyberthreats it protects against, is always expanding. As new capabilities come to cybersecurity, cyber criminals hone new attack strategies, explore new attack vectors, and plot new ways to extract returns on their illicit business models. Today, cybercriminals are turning to a new frontier in cybersecurity: product security and the software supply chain.

But, there’s a vast chasm between watching this great expansion of the universe of cyberthreats and acting on that knowledge to better secure your connected devices and embedded systems.

After you’ve tackled the basics such as, what is product security?, and why do I need to worry about supply chain security?, all organizations eventually find a common first step when they successfully begin the road toward secure products and software supply chains.

The first step is, and should always be, discovery.

Discovery: Why care about product and software supply chain security?

Whether you’ve built your connected product, or bought it from a supply chain partner, you can’t begin to improve your security posture if you don’t know what your security posture is.

At Step 1 in your connected device security journey, you should be asking:

• What code have we built?
• What code have we acquired through open-source libraries?
• What code came with devices from upstream supply chain partners?

If you’ve built your connected device entirely in-house, you probably own all the source code and it will be available to you.

But, even for the largest OEMs, that’s almost never the case. Almost all organizations rely, at least in part, on open-source libraries and code from software supply chain partners.

Do they have the same control environment rigor as your organization? Are you willing to bet your product’s reputation on that educated guess?

What if you have all the source code?

Even if you have all the source code, connected devices can come with mysteries as opaque as the black holes at the centers of galaxies. Consider:

• If source code has already been compiled into binaries, many SCA methods can’t penetrate it.
• If your source code has changed since your official source report, the code you sit down to assess may not be the code that your product uses right now.

How do you see into your connected devices and embedded systems? How do you see into the black holes that binaries bring to your product security posture?

Find a solution that features binary analysis. Those solutions can help you reverse-engineer binaries and help you see into software risk, in near-real-time.

Bottom line, you need a solution that helps you see beyond source code and into a product’s binaries, credentials, certificates, and configuration files. You need to see into the product you’ve got sitting in your shipping area, not the one you planned to build when you first set out to solve customer problems.

Ready to learn more? Read our Ultimate Guide to Connected Device Security

To truly defend your connected product—and the services it will provide—you need a solution that shows you your whole product—and your unique set of vulnerabilities and attacks. That’s why this first step of the connected device security journey—discovery—is so critical.

Wondering how to start your road to more secure products and software supply chains?

Finite State’s Ultimate Guide to Connected Device Security explores product and software supply chain security and how to identify, assess, prioritize, and mitigate the vulnerabilities that lurk within your connected devices.

Ready to learn more? Download Finite State’s Ultimate Guide to Connected Device Security.