The actual figures are hard to ascertain, as the consequences of such things as IP theft are more difficult to assess than emptied bank accounts.
It is no wonder, then, that designers are looking to design in security from the start, rather than think about it as a retrofit option – an option that cannot yield security levels on a par with designed in security solutions.
The key here is the level of connectivity brought about by the Internet of Things. Every connection increases the security risk and if, as predicted, there are some 30bn connected devices by 2020, that represents a lot of security risks.
When charged with developing a secure system, where should the designer start? Is it with the hardware, the operating system or the application software? Three experts in the field – John Blevins, director of marketing for LynuxWorks, David Kleidermacher, cto of Green Hills Software, and AJ Shipley, chief security architect at Wind River – believe there is a multitude of considerations involved in developing a secure embedded system.
It all starts with people
Shipley believes that problems start with people. "The weakest link is often the human element, although often deeply embedded devices don't have that – they don't have to worry about a person clicking on a link and installing some type of software. However, traditionally, the biggest weakness has been in how the coding has developed. Weaknesses are typically introduced by accident as a part of the development process, primarily because there is not a good understanding of how code needs to be developed – how security needs to built in through the process."
Part of the problem, at least, goes back to increased connectivity, according to Blevins. "By attaching something to the internet, it becomes subject to all the attacks that are out there against the enterprise world, the pc world, the server world and so on. We want to make sure people are prepared for that – embedded developers have not always had their devices on the internet and have taken the naive approach that they built the device, it runs fine and they are not concerned about the possible attacks that could come when their device is attached to the internet."
"If you don't start with a secure foundation, which is the operating system, there is no sense in implementing application security because you can always get underneath it," commented Kleidermacher, who said this, along with skilled security code writers and a knowledge of relevant protocols, provide the three key starting points when developing a secure environment.
When looking from the perspective of designing a secure embedded device, the application software, the most likely point of attack, can have its own levels of security, but the effect on the system in terms of infection or invasion will be determined by the operating system. Equally, the hardware has a bearing on the level of security possible.
Blevins explained: "A lot of chips have security features built in; the problem is there is no consistency across different architectures – Intel has some things, ARM has others – so being able to have relatively portable code bringing the security features up to the operating system is probably a better way of doing it, especially when the operating system and the applications are the things that are typically the most vulnerable."
"If you think of all the attacks in the pc world, they are all against Windows or getting underneath Windows or attacking Windows device drivers," he continued. "The real vulnerability now is in the operating system and I think that is why a lot of people really don't trust using a regular operating system in their embedded systems."
System security, our experts agree, therefore rests largely with the operating system.
In a constantly evolving environment, security levels within operating systems are difficult to guarantee, but one way is using the Common Criteria, the international standard for IT security evaluation. It rates all products from one to seven, where seven is equivalent to a mathematically proven guarantee of total security.
Systems can only be certified to the security level to which they were originally designed. Operating systems like Windows, Linux and Android were designed to be sophisticated, rather than secure. They have a huge 'surface area' – millions of lines of code – to attack and so have an security rating (EAL) of 4+ and no amount of patches can allow them to go higher than this.
Dedicated secure embedded operating systems can go further than this. Green Hills' flagship OS Integrity has been certified EAL7. "Given our pedigree of being the only OS company to have reached that EAL7 certification, there are two things that people should infer," claimed Kleidermacher. "One, obviously, that we have an OS that is secure – the second is that we have a process for building security and we can help people do it on their software."
There is another strategy – to develop virtual machines with a hypervisor running a separate and secure layer between the hardware and the operating system(s). The advantages of this are, firstly, that system security can be upgraded, even if the operating system cannot and, secondly, the benefits of running a more sophisticated OS to create, for example, a better user interface. More than one operating system can run on top of the hypervisor, allowing different levels of security or functionality.
Has security become embedded?
Has designed-in security now become the norm – is it being taken seriously? Shipley believes it is moving in that direction. "In general, designers are taking it increasingly seriously. You are also seeing non deeply embedded vendors like Microsoft taking it more seriously. While everybody recognises there is a problem and that they need to take security more seriously, what that means is different depending on who you talk to.
"The bigger issue – how you pay for it – is probably the aspect that is not being given an adequate amount of consideration. For the most part, implementing better security has a cost associated with it – not just in engineering expense, but also in the potential cost in terms of user experience, or the cost of privacy.
"While big corporations have risk assessment frameworks in place to help them run their business and assess the different risks to their business, only recently has security, or cyber security, been introduced into these frameworks. Quantifying the cost of security is challenging, but that is just because it is a relatively new thing. The people in the companies who have to do it don't have the experience in security and so don't know how to measure it."
