39% of embedded engineers report designs that incorporate web components. This figure is expected to surpass 50% within the next two years. This dynamic represents a material shift in the design considerations undertaken by many organizations given the breadth and growth of applications expected to gain web connectivity over the next few years (consumer electronics, white goods, automotive, situational awareness, etc.).
Recent international news, however, has highlighted the growing threat facing cloud-based applications. Sony’s PlayStation Network was (repeatedly) hacked, exposing thousands of customers’ credit card information. Just yesterday, Lockheed Martin announced that it had suffered a "significant and tenacious" cyber attack, in effect exposing the government’s largest IT supplier. With more and more interconnected devices serving as new potential waypoints for network intrusion (as well as access points to locally-stored sensitive information), it is time for an industry-wide introspection into the best practices around secure device development.
Clearly, this is not a new issue or consideration for some embedded verticals markets (i.e. military/aerospace). Many other applications classes, however, were originally autonomous systems with no sustained connections to the outside world. This is no longer the case. More and more devices are now requiring connectivity requirements to remain relevant.
How do you protect your system?
There are a number of methods that engineering organizations are undertaking today either through the implementation of aftermarket fixes (think COTS security solutions, e.g. secure routers or firewalls) or within the development of the system itself. To focus on the “secure by design” methods, which we believe to be a critical first step to secure device deployment, we view there to be three distinct approaches: development tools targeted at precluding the introduction of security vulnerabilities, testing tools, and the implementation of specific run-time software (e.g. RTOS, hypervisor, etc.).
It is perhaps not surprising that over 40% of engineers did nothing or did not know if anything had been done during their current project to limit security issues due to the number of remaining embedded devices that lack web connections. What is surprising, however, is the limited overlap between the techniques undertaken by engineers whose organizations are taking proactive steps to preclude the introduction of security issues. All of these techniques can help reduce application vulnerabilities but none of them is a cure-all and should be used in isolation.
Whereas the accountability for security issues can be broadly painted across product stakeholders, perhaps the greater issue is education. End customers cannot expect developers to develop secure products unless it is specified in the requirements nor can they expect all engineering organizations to approach their due diligence in the same manner. Part of the issue may also fall on the security solution vendors themselves whose value proposition articulation is purposefully myopic – to maximize sales of their own products. Clearly, the industry needs a coordinated effort to evangelize the issues and suites of solutions/practices required to limit security vulnerabilities.