Securing Devices that May be “Smart” but Insecure

If you listen carefully to most discussions of cybersecurity, you can hear an assumption—often hidden—that deserves more attention: Exploits and vulnerabilities are assumed to exist. We have vulnerabilities, which hackers exploit. Ergo, we must work harder on defense. The vital, usually missing question involves how these vulnerabilities got to be there in the first place.

Insecure design is a given. Without it, there wouldn’t be much of a cybersecurity industry. It’s such a massive, foundational fact of the sector that we tend to ignore it. But, we shouldn’t. Just because today’s dominant hardware and software platforms were designed without much (or any) concern for security, that does not mean we should continue to create such products.

Firms like IOActive are addressing this problem. IOActive offers security services that include technology audits that reveal security problems in hardware and software, as well as in systems like a smart city network. They often work in the development lifecycle, which is where many security weaknesses are inadvertently designed and built into the final product.

“It’s easy to lay the blame on developers, but that’s not quite fair,” said Cesar Cerrudo, IOActive’s Chief Technology Officer. “They’re working on a schedule that’s oriented toward time-to-market, not security, per se. And, security is not their background, typically. We can come in and evaluate the product and the development process to identify security risks before the end product gets into distribution.”

It’s easy to lay the blame on developers, but that’s not quite fair. They’re working on a schedule that’s oriented toward time-to-market, not security, per se.

In the case of smart cities and Internet of Things (IoT) devices, IOActive can reveal security flaws at the device and network levels. Cerrudo offered the example of a smart city device like a sensor that works with deficient encryption or no encryption at all. “In our smart city work, we tend to see devices that have not had their encryption turned on. This of course creates a huge risk, because anyone who knows the frequency of the device, can meddle with it. They can install new firmware and cause all sorts of other problems.”

Other design flaws that create risk exposure in smart city devices include practices like embedding the encryption key in the device itself or assuming that a hacker cannot access a device because it uses custom vendor protocols. Another bad design choice that Cerrudo has seen involves assuming that a device can only be accessed by trusted people or devices. “If you take a very hard look at the device, including all of its exposed attack surfaces, you can usually find weaknesses where a hacker can make changes to configuration without a username or password. For example, with a firmware update, you don’t usually have to sign it. It can be modified without detection. This can lead to disaster.”

It’s an organizational and structural problem. The city isn’t knowledgeable, or if they are, they don’t have the resources to audit and follow up adequately.

The underlying problem, in Cerrudo’s view, stems from the government customer blindly trusting the device vendor. “It’s an organizational and structural problem,” he explained. “The city isn’t knowledgeable, or if they are, they don’t have the resources to audit and follow up adequately. The policy enforcement may be based on faulty mechanisms like questionnaires that are not filled out honestly, or at all.”

IOActive works with the device maker, or the city, to design security into the product and resulting smart city network. Their services mitigate the risks that arise from insecurely-designed products and sub-optimal deployment methods.

Photo Credit: Chuckwalking Flickr via Compfight cc