Secure by Design

So, your company has challenged you to design the next generation of embedded device. This is an IoT device for the next great idea that the C-suite is ‘betting the company on’. Only the best counts. This is a defining moment in your career!

So you set down to grab the best piece of hardware (that fits in the price band). You can do secure boot, you have a TPM to store and manage your keys, you have offload for encryption, you set up the best authentication you can think off, you are even exploring blockchain.

The world is your oyster! You reach out to Wind River for VxWorks, as you know that this operating system has stood the test of time, while still being modern. It is flexible, while remaining efficient. You can combine VxWorks with other OSes if needed through virtualization, you have it all!

Next, you set down to design your software and your development processes, you set up a stringent architecture with strong rules that you educate the team on. You have separate memory spaces for different types of information, you validate input that comes into your system before you use it. You use continuous integration, you have peer reviews. All is well.

Then time goes by, people leave the team, new people come on, education does not happen as prescribed, peer review gets more and more lax as time goes on. Then an intern that has just joined shortcuts the process and ‘fixes’ a bug, introducing a big buffer overrun read by not validating that a parameter that a function receives as input is within the proper values. As a result, too much data is copied out of your device and ends up ‘out on the wire’. If you are lucky, it is innocent data, in the worst case, it could be credit card data, passwords or other keys that are supposed to remain confidential.

While this scenario is certainly contrived, in reality it is not far from the truth. The security of your device depends on it’s weakest link and the weakest link is often the people developing the applications, from BSP up to middleware, up to business logic, of your device. A small mistake is all it takes, the National Vulnerability Database has lots of examples of things that have gone wrong in the past.

There are some easy steps that you can take immediately to avoid many of these types of problems. Static analysis tools are an easy add-in to your software development workflow. If you don’t have static analysis, then this is certainly a blind spot in your development cycle. Static analysis can immediately red-flag violations of security policies, either generic, or specific to your domain. If you use static analysis already, then maybe look into how well your static analysis tool handles data taint. Data taint is a generic security policy and refers to input that flows into your application logic and that is used in accessing memory structures, or in making decisions without properly scoping whether the input is in the right range. Want to know more, here is a white paper and here is a video that provides the background and examples as to how data taint can help you improve security for your embedded devices.