3 Reasons Embedded Security Is Being Ignored

The IoT has grown to the point that everyone and their brother is in the process of connecting their products to the Internet. This is great because it opens new revenue generating opportunities for businesses and in some cases completely new business models that can generate rapid growth. The problem that I am seeing though is that in several cases there seems to be little to no interest in securing these devices. (I draw this conclusion from the fact that embedded conferences, webinars, articles and even social media conversations seem to draw far less interest then nearly any other topic). In this post I’m going to explore the primary reasons why I believe development teams are neglecting security in their embedded products and explain why security doesn’t have to be a necessary evil.

Reason #1 – The Perception That Adding Security Is Expensive

I believe that there is still a perception in the embedded space that security is expensive. Right now, if you were to survey the availability of security experts, you will find that there is a severe shortage at the moment. Since our economic system runs on supply and demand, where there is a supply shortage, the cost for those goods or services will be higher. Security experts will often charge several hundred dollars per hour for their time and management will often look at those costs and assume that they need that expert for the entire development cycle. In reality, many embedded products don’t require a full-time security expert to be on staff. Having access to an expert up front to create a threat model and the security objectives and then periodically through-out the development cycle can be all that is required. The cost to a company for a security breach can be orders of magnitude more costly.  

Reason #2 – We Will “Add It Later”

Nobody wants to be on the front page due to a security breach. I believe in many cases, companies want to include security, but in the early stages of product development, when funds are short, security is often the lowest priority. With many good intentions, the teams often think they’ll add it later after we get through this sprint or this development cycle. The problem that is encountered here is that you can’t add security on at the end of the development cycle.

A secure solution requires a well-thought-out process that involves starting the security analysis from the very beginning of the development cycle. Developers need to follow a process like Arms Platform Security Architecture (PSA) which has them evaluate their systems assets and threats from the beginning. The advantage to doing this up front is that it helps to generate the security requirements and objectives for the system to protect those assets from the expected threats. This then leads to the selection of hardware that can support the security objectives and the software necessary to carry it out. Obviously starting at the end can result in the wrong hardware and software being selected which means either going back to redo it or accepting what is there at the cost of a less secure solution.

Reason #3 - Teams Are In Too Big A Hurry

Nearly every development team that I encounter is behind schedule and in a hurry. New start-ups, seasoned successful teams, there is always way too much to do and never enough time (or budget). In many cases, teams may be developing a new product and need to get to market fast in order to start generating revenue so that they can pay the bills. While they might be thinking about security and want their systems to be secure, the priority is to build a product that can generate revenue, which in many cases is very close to a minimum viable product. In these cases, we need to change our thinking for connected devices to include security as a core component in the minimally viable product. Rushing to market is never the right answer.

Conclusions: 

Security is a foundational element to any connected device. Security cannot be added on at the end of a product and must be carefully thought through from the very beginning. Without thinking about it up front, the development team can’t ensure they have the right hardware components in place to properly isolate their software components or expect to have the right software frameworks in their application to properly manage and secure their product. 

I’ve noticed lack of interest in security topics amongst embedded software and systems engineers which is a little bit frightening. While many of these reasons we discussed today may seem like real issues preventing robust security, there are many resources available to engineers to help them learn security and begin to implement it. Taking a few first steps such as learning how to analyze a systems threats and developing a threat model with security objectives can go a long way. There are even open source security frameworks like Trusted Firmware-M (TF-M) that can ease the development burden.

RELATED ARTICLES:

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website, and sign-up for his monthly Embedded Bytes Newsletter.