Tag Archives: embedded security

Vending machine image

Who is Taking Cybersecurity Seriously, and why You Should be Worried



May 28th, 2015

By Alan Grau, Icon Labs

On a daily basis, I have the opportunity to interact with a wide range of companies and people involved in embedded device development and cybersecurity for embedded devices.  I was recently struck by the difference in attitudes regarding cybersecurity at three diverse companies.  Each company representative had a very different approach in evaluating how and why to implement cybersecurity in their devices, and I found the differences in their approaches more than a little surprising, and in fact rather concerning. 

I understand the flawed logic of drawing broad conclusions from just 3 data points, but I believe there are still lessons to be learned from these perspectives on security, and that they are representative of widely held opinions. 

Approach 1: Blind compliance to standards

In discussions with an engineering manager who was working on a project for the United States military, I was struck by the single-focused objective of ensuring compliance with customer supplied security standards.  Yes, compliance to standards is important and provides a baseline for building secure embedded devices.   Many companies could very well improve the security posture of their devices by adhering to industry security standards. 

That said, I am not an advocate of blind compliance with external or industry security standards.  It is critical to evaluate the risks and attack surfaces of each device and provide security solutions that address the individual needs of that device.  My criticism of this approach is not the desire to achieve compliance with security standards, but the unwillingness to consider other security threats or attack vectors.

Approach 2: ROI for including security

A manager for an industrial automation company recently asked me “what is my ROI for adding security to my device?”  I understand the need for any business to focus on ROI and make sound business decisions, but I found it surprising that security for critical control system devices was using ROI as the key determining factor on any possible investment in cybersecurity for his products. 

Clearly, a cost-benefit analysis must be made on any cybersecurity investment, but some decisions (at least in my opinion), shouldn’t come down to just ROI.  I equate this to my life insurance policy.  I did some “business analysis” to determine how much life insurance I felt I needed, but I didn’t buy life insurance for the ROI.  I hope to never use the insurance policy, and if I do there is no ROI for me, but I still purchased the policy because it is the right thing to do. 

The calculation needs to include the cost of failure.  What happens if there is a successful attack on a system using this company’s technology and the company’s solution is then later to be found at fault? With the possibility of a cyber-attack costing millions of dollars in damages, can a company afford to not have insurance provided by including security technology in their products? The ROI may be in their customers’ confidence in the security of their offerings.

Approach 3: We need this to be secure

My final example is from a manager who is tasked with building the next generation of his company’s flagship product.  The previous generation product had limited communication capabilities, utilizing cellular data communication to “phone home” and provide diagnostics and operational information to back-end servers.  The next generation products will include Wi-Fi, Bluetooth, USB and Ethernet connectivity options. 

Vending machine image

 “With all the connectivity being built into this product, we need to make sure this is secure”, was the message from this manager.  This is the approach that more companies need to take.

 This company is concerned about security standards and ROI, but they have a broader recognition of the importance of security.  They recognize the need for the device to include adequate security based on its use cases and attack vectors, and that the tradeoffs are well thought out.  What is most surprising is that this company is not building automation equipment for industrial automation or military usage, but vending machines. 

Summary

There has been a tremendous amount of press regarding cybersecurity for critical infrastructure and embedded devices, including a presidential executive order. Everyone is worried about cyber-attacks concentrating on data – accessing people’s private financial information and stealing their money. However, if a cyber-criminal successfully attacks and penetrates control and communication systems at a utility, manufacturer, transportation, medical or DoD facility system, lives are at stake. People could die. This is a much bigger threat than a few million dollars, or a few candy bars, stolen by a hacker.

Companies are now finally becoming aware of the need to secure embedded devices and some companies are doing more.  But more is not enough.  If a vending machine company can make its objective “this has to be secure”, then so can everyone else.  The fact that a vending machine company is leading the way has me worried.

Alan Grau is President and co-founder of Icon Labs, a leading provider of security software for embedded devices.  He is the architect of Icon Labs’ award winning Floodgate Firewall.  Alan has 20 years of embedded software experience.  Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola.  Alan has an MS in computer science from Northwestern University. You can reach him at alan.grau@iconlabs.com 

Are you taking embedded security seriously?



February 4th, 2014

A lock with the key still in it isn’t much of a solution. Sadly, the security in many embedded devices isn’t much better.

By: Alan Grau, Icon Labs

At the gym last week I noticed a locker secured with a padlock but with the key still in the lock. One of the assumptions of locking something up is that there is something worth protecting. If the contents of the locker weren’t worth protecting, then don’t bother with the lock. But if you are going to bother with a lock, or with adding security to your embedded device, you might as well make sure the security will work. A lock with the key still in it isn’t much of a solution. Sadly, the security in many embedded devices isn’t much better.

Is this your embedded security solution?

Is this your embedded security solution?

Many embedded devices have been built with very little, if any security. Too often what security is provided is insufficient. In June 2013, ICS-CERT (Industrial Control Systems Cyber Emergency Response Team) published a list with more than 300 medical devices from approximately 40 vendors that used hard coded passwords, almost the literal equivalent of leaving the key in the lock.

Other embedded devices are using out of date crypto standards. For example, keyless remote vehicle entry systems utilize encrypted RFID signals. Most implementations use a 40 bit encrypt key. When the standard was first introduced in the 1990s 40 bit encryption keys would take days to crack, but not today. A google search of “keyless vehicle entry systems hacked” turns up a number of articles describing how thieves are exploiting this weakness to steal cars.

Security – Priority or Afterthought

While embedded devices are very different from standard PCs and require unique solutions, the biggest challenge to embedded security isn’t technical.

Too often, security is simply not a priority. I recently received a call from a company putting together a requirements document for a critical new piece of technology for a Fortune 100 company. This was a core piece of technology that was to be used across a majority of the company’s products. As this document was being finished they realized they had not addressed security and they didn’t have the expertise in house for this task. They wanted to see how they could drop in some security at the last minute. While they were still in the requirements phase and there was time to address it, security was clearly not a priority despite the fact that this would go into a product that virtually everyone in the developed world uses on a daily basis – and a security breakdown could literally result in the loss of life. Sadly, this is not the only example I have seen in which security is an afterthought.

Security for Modern Embedded Devices

A security solution for embedded devices must ensure the device firmware has not been tampered with. It must also secure the data stored by the device, secure device communication and protect the device from cyber-attacks. This can only be achieved by including security from the early stages of design.

There is no one one-size fits all security solution for an embedded device. Security requirements must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the length of time the device will be in service. Many embedded devices will still be in service 10 or even 20 years from now. Given Moore’s Law, an encryption key that provides strong encryption today may not hold up for the next two decades.

Embedded security features that need to be considered are:

  • Secure Boot – Achieved using cryptographically signed code from the manufacturer along with hardware support to verify code is authenticated. This ensures that the firmware has not been tampered with.
  • Secure Access – Access to the device (remote login, access to a web interface, etc.) need to be secured with encryption and a strong authentication method. A strong password or an authentication method such as Kerberos can be used.
  • Secure Communication – Communication to/from the device needs to be secured using encrypted communication (SSH, SSL, etc.). Care must be taken to avoid the use of insecure encryption algorithms.
  • Embedded Firewall – Embedded firewalls provide a critical layer of protection against attacks. A firewall can limit communication to only known, trusted hosts, blocking hackers before they can even launch an attack. A layer of defense to protect against common attacks such as packet flood attacks, buffer overflow attacks and known protocol exploits.
  • Summary

    If security is made a priority, I believe engineering teams are more than capable of building much higher levels of security into their devices. Solutions are available for including encryption, secure boot, authentication and firewalls into embedded devices. The key (no pun!) is that security needs to be considered early in the design of a new device or system. Support for secure boot or device tamper detection requires specific hardware capabilities. Since hardware is typically selected early in the design phase, this capability must be considered very early in the process. Since many embedded devices are deployed outside of the standard enterprise security perimeter, it is critical that security be included in the device itself.

    Alan Grau

    Alan Grau is President and co-founder of Icon Labs, a leading provider of security software for embedded devices. He is the architect of Icon Labs’ award winning Floodgate Firewall. Alan has 20 years of embedded software experience. Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola. Alan has an MS in computer science from Northwestern University. You can reach him at alan.grau@iconlabs.com