Unhackable: 5 Ways to Connect with your Engineers on Embedded Software Security - Bluefruit Software

Your browser is no longer supported. Please upgrade your browser to improve your experience.

Smart appliances, robotics and other embedded-software devices are increasingly making our lives easier and in many ways, more dynamic. As we’ve heard time and time again, the Internet of Things (IoT) is the future. From Ikea’s charging furniture to Withings’ smart thermometer, businesses know investment in technology is critical for long-term customer interest and partner investment. However, as well as new opportunities, the growing interest in connected products also introduces businesses to new challenges.
One of the greatest risks when developing a smart/connected product is security. As we’ve seen with the Wannacry attack and the further global attack on the 27th of June, there’s no shortage of hackers seeking vulnerabilities to exploit. Innocent devices like light bulbs have been targeted to gain access to user’s Wi-Fi and networks. The New York Times ran a full article on this vulnerability and Thomas Ricker of The Verge warned “expect things to get worse before they get better.” Consumer group Which? also recently published a report on the Hackable Home.  As Nicholas Fearn points out in his Tech Radar article on the topic, our ever smarter world is increasingly vulnerable to attack.
Secure products rely on the expertise of software developers. To ensure you’re using proper security, the first place to start is with some fundamental checks with your software developer around the quality of your code and the security needed for your device. To help, we’ve put together a list of 5 practices that any product developer should review with their software engineers to ensure that the right steps are being taken to protect both your products and more importantly your users.
1.     IDENTIFY THE RISK 
Security in software is a hot topic in this era of mass attacks.  We suggest starting the security conversation by first clearly determining your risk profile. This  can be established when you first outline the project scope and planned development work with your software engineers. In the security industry, assessing risk is termed, “threat modelling”. It’s important that from the very beginning you and your engineers are thinking about how your device will be used and most importantly, for security, how it might connect to other devices or networks. A very complex product could be safe if the code is contained to just the device. However, devices with simple functions could present a bigger risk than you’d expect. If you are designing software that will live on a network, it’s a good idea to get in a third-party security expert, assuming you do not already have one as part of your permanent staff. 
In the embedded world, there are other risks too. If you’re not careful and leave debug UARTs available for example, or worse, Command Line Interfaces (CLIs) that let people tamper with the software via those UARTs, they could misconfigure the software in a naughty way. Security professionals will assess and mitigate your risk using battle-hardened, peer-reviewed protocols and libraries. Their knowledge will ensure your device(s) is safe no matter its size or function.
For example, does your product need an operating system? If not, can it use a different hardware?  Being flexible equals efficiency. Using inappropriate hardware, code, etc . means your product may have security risks/need patches that aren’t necessary to serve its function.         
2.     CREATE CLEAR SPECIFICATIONS
Whenever working with an Agile software engineering team, be sure to ask for a project-wide security strategy at the start and then detailed-project specifications for each sprint of the project. In addition to defining the delivery plan for your requirements, the spec should be the first place where any initial issues are raised. By having a clear breakdown of the functionalities against the user experience, the developer can start to highlight potential security break opportunities. 
A spec should speak to you in plain English and your developer should be able to clarify any technical terms. Many business owners are slow to ask for clarification – a miscommunication/ missed communication often creates security vulnerabilities. Each part of the software should be identified in the spec and along with information on its necessity.
Good developers provide thorough and cogent specs. Ensure you have an ability to access and discuss with your engineers. Don’t rely too heavily on salespeople and account managers to know the details of the tech used on your project. You should have a top-level knowledge of every component of your product and understand the functions of the software.
At Bluefruit, we find  a meeting(s) that brings the client, at least one member of the testing team and at least one of the software engineers together highly productive . This is often referred to in agile as a “three amigos” meeting. From this meeting we plan out our next burst of work (we call it by its agile name, a “sprint”) and identify any known issues. By having the client, the engineer(s) and the test engineer(s) all on the same page we can ensure we’re looking at all sides of the product development.
As part of discussing the specs, ask  engineers for a risk profile that can be pitched to other colleagues/funders/other professionals/business owners.  An inability to provide this may be a red flag that potentially highlights a need to go back to threat modelling.

3.     PROVIDE UPDATES
Did you know that the NHS hack could have been prevented with just a simple windows update? Updates aren’t limited to computer software. Devices need updating regularly as well to ensure that they are protected against discovered hacks and just to ensure a better user experience. Before you even start a new project, ask your engineer what is their plan for ongoing maintenance. Who is responsible for checking for updates? How will you know the software is up-to-date? Is your product even updatable in the field?
Your engineering team will provide up-to-date patches and have an ongoing maintenance plan. It’s important to have a channel for software updates and a strategy for providing those updates – these updates could be in the form of patches for discovered vulnerabilities or improved user experience. Don’t be shy about asking your engineer for a timeline.
4.     3rd PARTY TESTING
You might have the best software engineers in the world working on your project, but when you are writing thousands of lines of code, things can get missed. The past year we’ve seen several large  businesses launch new products that were vulnerable to hackers from launch.
This testing is a critical stage in software development. The more people that review the code, the more likely you are to find all the bugs before it goes live. Test Driven Development (TDD) and Behaviour Driven Development (BDD) can help with this, but if your product has a high security risk you may need an additional level of security. One way to achieve this is to bring in a 3rd party security testing partner, whose entire job is to try to hack into your device before it’s put out to market and in the hands of real hackers.  At Bluefruit we’ve worked with the Ethical Hacking team at Plymouth University to triple check our work for any devices our clients want extra secure. 
Ask your software engineer  about third-party testing. Who do they use? What is the third party’s reputation? Is your engineer willing to use a third-party tester of your choice? Whether you employ in house or a development company, your product’s code should be tested by a third party.
5.     STICK TO YOUR THREAT MODEL
Once the threat model has been established do not be tempted to deviate from it. Software can always be made more secure but adding security without reference to the threat model is redundant.  If whilst developing, you feel the need for more security – you should revise the threat model then revise the security. The threat model should have primacy. Doing less than the model exposes your users to unnecessary risk and adding more security without returning to the model is redundant. 
In short: stick to what you’ve decided and don’t add security as an afterthought.
The world of embedded software has endless possibilities and makes for a more exciting, more connected future. What do you think of these 5 Security tips? Comment below to tell us if we missed one or share with us on Twitter and Facebook.