No Easy Answers for Hardware Security Threats



altby John Linkous

When most of us hear the term “security breach,” we tend to think of network-based attacks against traditional computer systems – such as databases and web servers – located in data centers or perhaps in the cloud. However, the landscape of security is changing as the potential threats to computer hardware, including general-purpose computers, specialized hardware such as smart meters and smartphones, and even individual computer components, are increasing dramatically.

Certainly, design flaws are a possibility with hardware, and always have been. Developers of embedded technologies, such as application-specific integrated circuits (ASICs), are very careful to review and test their designs before committing them to production because they understand the potential ramifications of hardware flaws, including security design flaws. Unlike patching a computer operating system or an application, hardware fixes often require low-level flashing of the equipment’s non-volatile memory, which typically requires manual intervention on the part of the equipment buyer and cannot be implemented through “auto-update” processes. In some rare cases, design flaws even exist at the hardware level, and cannot be remedied with a software-only solution at all.

However, while the possibility of design flaws has always existed for hardware technology, there are a number of other causes for a relatively recent increase in the attack risk to hardware. One cause is the fact that so many pieces of technology have migrated from proprietary, electro-mechanical hardware to commoditized components based on standard, general-purpose computers and networks. The so-called “Internet of things” is rapidly becoming a place filled with household appliances, cars, and other components that have never previously been “attached” to anything else… and the ramifications of doing so are usually not very well thought-out. A great example of this is “smart meters,” which energy companies are adopting at a very fast rate; these devices are based on common, commoditized hardware, and in many cases rely on networks using standard protocols such as TCP/IP. While there is no doubt that the migration to common hardware, operating systems and protocol stacks will result in better manageability, the sad fact is that security remains a laggard behind functionality and efficiency with these migrations. If common, well-known attack vectors are not patched or otherwise addressed, these components based on commoditized hardware are going to provide a method for attackers and malware to compromise systems that frequently have real-world ramifications, not just concerns for data: imagine a smart meter being hacked to slowly increase the temperature of a home at night by 20 degrees, or a refrigerator remotely programmed to defrost at two o’clock in the morning.

Another cause is the fact that the likelihood of the threat has increased from potential corruption of individual, globally sourced components, to (in the case of the United States, and likely other nations) government agencies such as the NSA, which allegedly compromise hardware through modification of BIOS and other low-level embedded technology. These potential issues with hardware supply chain corruption can create significant problems, both in terms of intentional exploitation as well as unintentional vulnerabilities that leave unknowing buyers of such hardware open to massive attack and data compromise.

Historically, when problems (including hacks) arise in traditional computing technology, digital forensics can be used to identify the root cause of the problem. However, hardware presents its own problems in this area, too. Digital data forensics is a discipline that’s based on several key concepts: preservation of the device(s) containing target data; acquisition of the data in a manner that minimizes the possibility of contamination or corruption; and examination and analysis of the target data. Unfortunately, when capturing this data from hardware, all of these practices are made more complex. Take acquisition, for example: capturing data from a hard drive on a computer is a relatively simple process; hard drives have a few common interfaces, and they store most of the information required for a forensic analysis, such as the operating system, configuration files, applications and data. Sure, there are some exceptions (such as the BIOS, which resides in non-volatile memory elsewhere in the computer), but for the most part a forensic analysis on a hard drive can be accomplished with relatively little effort or customized equipment. Now imagine the same effort with a mobile phone. First, the critical data is split between different discrete locations, including the universal integrated circuit card (UICC) – better known as a SIM card – as well as several types of non-volatile RAM, and removable media cards (such as microSDXC). Moreover, each of these storage mechanisms comes in a different physical form factor, and with the fragmentation of different makes and models of mobile handsets and devices, the specific procedures for capturing critical forensic data can vary wildly.

Together, these hardware-based threats are much more difficult both to detect and to mitigate than more traditional, software- and network-based threats. However, there some things that hardware vendors and the businesses that buy and use their hardware technologies can do to reduce these risks… at least somewhat.

For vendors, the first and most important step is to ensure that security is engineered into products from the start, and isn’t simply a “bolt-on” function. What do I mean by that? Here’s an example: one major vendor of supervisory control and data acquisition (SCADA) programmable logic controllers (PLCs), which are used heavily in the energy distribution industry, released a product that had a username and password security control for access – but published the default password in their documentation, and recommended that buyers not use this authentication capability. Security controls that aren’t implemented don’t count as security. Vendors need to conduct risk analyses on their equipment, and embrace security at all appropriate layers where it’s warranted: from physical non-tampering controls, to authentication and encryption controls around data in transit and at rest. This is particularly true for vendors who are focused on building technologies using standard, commoditized components and protocols.

Another key step for vendors is to ensure the integrity of their supply chain. While most large vendors have long-standing relationships with incumbent component providers, there are times when supply chains become affected by natural disasters, economic issues, and other concerns that require a vendor to source another supplier. In those cases, vendors need to ensure that not only their suppliers’ product quality meets specifications, but also that their own supply chain for components is not compromised – either intentionally or accidentally.

Finally, it’s safe to assume that, at some point, a vendor will need to upgrade products (due to a security update, feature improvement, or some other reason). It’s critical that hardware vendors maintain an effective downstream communication path to their end customers to ensure that these consumers are made aware of the most critical updates and (if necessary) recalls. Similarly, for self-service updates that can be accomplished by the customer, it’s important for vendors to maintain a section of their website dedicated to support, where instructions, flash code, software tools and other self-service components can be easily located and installed by c
onsumers.

For buyers of technology, these issues aren’t as simple to address. The most effective solutions are identifying the gaps in security that exist within hardware products, and building controls around them. Installing anti-malware on smartphones and tablets, ensuring that “smart” appliances are properly firewalled through the home network, and turning off unneeded and unused interfaces and APIs to hardware are all effective solutions for closing the security gap and minimizing hardware threats.

While there are no easy answers to the problems of security introduced by hardware devices, a combination of improving vendor acceptance of security controls, coupled with a defense-in-depth security strategy implemented by consumers around these technologies can help to reduce the overall risk.

John Linkous is a Security Research Fellow at EiQ Networks.

 

Leave a Reply

WWPI – Covering the best in IT since 1980