Embedded device security is not always a straightforward pursuit. Devices are more complex, more connected, and more numerous. Regulation and legislation also increase the pressure on OEMs to maintain the highest security standards. How can device makers build secure embedded systems, and what role does hardware play?
What are the best practices in embedded security, and how can OEMs implement them? How can using a system-in-package (SIP) help improve device hardening?
We got together with our partners at Octavo to answer these questions, and more, in our Best Practices for Building a Secure Embedded System webinar here.
You can also read the highlights below.
Best Practices for Secure Embedded Development
There is no one-size-fits-all approach to embedded security. However, there is one thing you can be sure of:
“A system without security in mind will never be secure,” – Chris Earls, Embedded Software Engineer at Witekio.
The strongest foundations support the tallest buildings. You can take advantage of the Agile methodology to instill secure-by-design principles into your product from the ground up. You don’t want to just fix problems as they arise, but also the process that led to them in the first place.
You Can Never Have Too Many Risk Assessments
Performing risk analyses, mitigating those risks, testing the new iteration, and starting the cycle again will ensure you have a product that performs well without compromising on security.
Some factors to include in your risk assessments include:
Requirements Risk Assessments
- How critical is security for this product?
- What environment will the product operate in?
- Who will have access to it?
- What data protection/privacy requirements do you have?
Architectural Risk Assessments
- Which components are exposed to users?
- What about privileged users like employees/admins?
- What is the exposure to other hosts on the network?
- Is there any exposure to other unknown peripherals (such as USB sticks)?
Test, Test, Test!
You are, of course, already doing testing, right?
Good. But how do you know which security tests to write and perform? This should be made easier by your risk assessments, but an incomplete testing process can result in overlooked vulnerabilities or misleading results.
Firstly, some tests can be automated, while others must be done manually. Make sure you are aware of where you can save time and where you need more involvement. Unit testing, white box testing, and black box testing can all help iron out any wrinkles on your code or hardware setup. Your device, ideally, will be used by people outside the development process, so penetration testing and fuzz testing are needed to protect it from malicious actors and clumsy users!
Ideally, OEMs will perform all of these tests multiple times throughout the development process, but knowing how and when to implement each test requires an expert understanding of embedded security.
Maintenance = Security
Even with a secure development lifecycle, your device will eventually become vulnerable over time, thanks to the sheer complexity of IoT devices and their associated networks.
A robust system of monitoring, detecting, and mitigating these CVEs is a must for any OEM looking to keep their device on the market for any length of time.
Device-makers must also plan system updates. Periodic system updates enable you to keep your OS optimized, add new functionality to your device, and plug new holes in your network. Remember, device security and network security go hand-in-hand.
It’s time to talk about hardware
Your hardware choices play a huge part in the security of your device. We can break hardware security down into four categories:
- Communication Security: Using tools to correctly transmit data from one point to another while ensuring its integrity along the way.
- Boot Security: Making sure you can trust, and protect, the software running on your product, usually by authenticating and encrypting your boot.
- Runtime Security: Maintaining the integrity, confidentiality, and availability of the different applications running on your processor, often by escalating privileges.
- Physical Security: Protecting the system from physical attacks on the device itself. Where a device might previously have been in a secure room, it has now migrated to the edge, giving attackers 247 access to it.
SIPs and Security
Using a system-in-package can be a great way to simplify and speed up the hardware aspect of your embedded development. But how does it affect device security?
Erik Welsh, CTO & Applications/Systems Manager at Octavo, explained:
“This takes what you’d normally put on a PCB, and all the exposures those components have to attackers, and integrates them into a single molded plastic device.”
By using a SIP, you can greatly reduce the number of physical attack vectors your device has to begin with. With Octavo, you can pick and choose the components that meet your security needs, as Octavo works with ST, AMD, and Texas Instruments, to name a few. Thanks to their system design expertise, you can be sure that an Octavo SIP provides the right foundations for your device hardening.
How can Witekio help?
Embedded security is complex and can pull in-house resources away from their focus. Fortunately, Witekio can help. With over 20 years of embedded software development, we know a thing or two about CVEs and device hardening. We have taken a “secure by design” approach since day one and can share our expertise with you in our security workshops. Using comprehensive threat surface analyses, we provide you with a robust blueprint for all your secure development needs.
For devices already on the market, we can take care of all your future cybersecurity needs with our long-term maintenance service. From daily risk monitoring and instant vulnerability alerts to CVE patches and kernel updates, we are your end-to-end embedded security partners.
