The other day I was participating in an InfoSec working group when one of the participants asked a pertinent and uncomfortable question:
“If there is so much hardware support for better security, why do we not see more of it in products?”
The answer is multifaceted:
- Embedded security is an emergent property. Only in the last few years has this become a highly visible concern, but many embedded devices have a lifespan of 10 years or more
- Embedded security does not have obvious engineering solutions. This makes it hard to quantify for many development teams, schedules, and budgets
- Manufacturers don't see security as critical to customer purchasing decisions
- Manufacturers don't know how to quantify their own security risk
- Manufacturing management thinks that their "fresh out of college" or cheaply outsourced development teams are “security experts” and will just do it correctly (hint: they are not, and they will not)
- Embedded security may not be a concern for a manufacturer motivated by the wrong reasons (i.e., short-term profit)
- New hardware security mechanisms are not well advertised by ARM / STM / Silicon Labs / Renesas / and others. Even when you know where to look and what to ask, required information can be hard to obtain
- Engineers don't understand embedded security. As an example, I have had otherwise competent software engineers tell me that once their software is compiled it cannot be de-compiled! They are amazed when I do it in seconds (the most recent occurrence of this was 3 days ago)!
- The current security practice in embedded development lifecycle of devices often looks like this:
- Someone in the development team makes a list of all the security risks they can think of (which usually isn't even close to being complete)
- These get included in the project as product security requirements
- Security is ignored until the first Release Candidate is ready, at which point a 3rd-party penetration tester attacks the device and gives you a report of all the security mistakes you made
- This is way too late in the product development cycle to do anything about them, so the vulnerabilities continue to be ignored (because no project manager wants to admit they messed up) and the product is released.
To be effective, embedded security must start the first day of the development project. Security can never be “bolted on” to a product as an afterthought. It is achieved during development, or not at all.