Insecure firmware is running on millions (and soon-to-be billions) of devices. Connected cars, coffee pots and cardiac devices house embedded firmware that’s often highly vulnerable and easily hackable. Why? It literally all comes down to the firmware’s code: how it’s constructed, what’s left inside and what’s included from the outside.
Think about these three points, which are tied to actual exploitations and hacks:
It’s ironic that secure coding practices are decreasing at a time when overall security practices are increasing. But, in today’s frenzied development environments, the faster developers must build code and the more “cooks” involved, the greater the chances for insecure coding.
With many forces at play to foster insecure coding on devices, security might seem like a pipe dream. Yet, consider the huge number of security holes in Windows software that were corrected over time. Through automated firmware evaluations, it’s neither difficult nor time-consuming to review a compiled firmware image and fix the code.Insecure coding is the basis for all IoT security issues; mitigating firmware risks hinges on evaluating and securing firmware before production. It’s everyone’s responsibility to secure their firmware in this global IoT village. We’re all as strong as the weakest link and risk mitigation must become a top priority for those who build code for embedded devices.