Welcome to part 2 of our ongoing series of blog posts exploring product security and the software supply chain. In our last blog post, we covered the first step—Discovery—that companies take on the road to connected device security.
Today, we move on to Step 2—Assessment. If you’d like to jump ahead and see the rest of the six-step process, or even just look at everything, all at once, you can read our comprehensive whitepaper, The Ultimate Guide to Connected Device Security, here.
Assessment: Transforming Data into Actions
If you were buying a car and built a discovery stage into your process to learn everything you could about its known problems and whether they apply to a particular vehicle, what do you do with all that information when it’s time to make a decision? How do you know which issues apply to this car, and if they matter?
Device security isn’t much different. Even after you determine what you have in your device, you still face the big step of understanding what it means.
At the start of the Assessment stage, you face two types of third-party code:
- Open-source code
- Proprietary code
CVEs (Common Vulnerabilities and Exposures) can exist in both—if researchers have found them in proprietary code and published their findings.
But, what’s next? To start determining which vulnerabilities and weaknesses your connected device has, you’ll need to reconcile every package—whether it’s open-source or proprietary—against CVE feeds containing publicly disclosed cybersecurity vulnerabilities.
When you match vulnerability data to the components you identified during the discovery stage, you’ll generate a list of vulnerabilities for your connected device or embedded system.
During the assessment stage, it’s also important to watch for CWEs (Common Weakness Enumeration) that can also be exploited and become new vectors by which cybercriminals launch their attacks.
How to Get the Most from the Assessment Phase
To get the most out of the assessment phase, look for a solution that offers binary analysis and you’ll get full visibility into your product’s code. When you check that code against known vulnerabilities and weaknesses, you’ll get a more complete list of CVEs and CWEs, and concerns that aren’t code-related like hard-coded passwords that offer backdoor access to your device and expired or improperly signed certificates.
A more complete assessment offers you the opportunity to find more of the security weaknesses in the code you execute as well as system-level weaknesses that enable attackers to reach that code.
Learn more: Read the Ultimate Guide to Connected Device Security
To truly defend your connected product—and the services it will provide—you need a solution that helps you make sense of your unique set of vulnerabilities, weaknesses, and help you understand which matter and how they can be mobilized against you. That’s why the assessment stage of the connected device security journey is so important.
Are you ready to begin down your own road to product security?
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.
Download Finite State’s Ultimate Guide to Connected Device Security today!
Share this
The First Thing about Software Supply Chain Security
Holistic Product Security Part 2: System Configuration
