NASA, Raspberry Pi, and the Need for a Security-by-Default Paradigm


NASA discovered back in April that an unauthorized and unsecured Raspberry Pi attached to its network had been hacked and 500MB of data had been stolen. Raspberry Pi is a great platform for rapidly developing connected devices and tools, and the security concerns for such devices are mounting as they gain popularity in global markets. Developers and network administrators must ask themselves: How much risk comes with a connected device or service on my network, and what can I do about it?

Well, devices connected to the public Internet or Wi-Fi are likely to be detected in an hour or less, according to The Internet Storm Center. Twenty years ago, a single device on the Internet could depend on security by obscurity as one small speck in the 3.7 billion address space of the Internet. Today, tools such as ZMAP can scan an entire IPv4 address space in about an hour. ZMAP is a tool used by academics and cybersecurity researchers, but many similar tools exist for legitimate and less legitimate applications.

Security by obscurity is obsolete.

Knowing that a connected device will be detected by third parties within an hour of connecting it to the network should concern the security-minded and prompt questions like “when my device is detected by intruders, how ready am I to fend off hackers?”

This is why companies started to ship Raspberry Pi and its variants with SSH disabled by default. Disabling SSH by default is a simple and effective solution when any hacker detecting a Raspberry Pi could apply the default username and password to get into the system. Disabling SSH completely closes that attack vector for hackers… until someone needs to use SSH and turns it on. Will they change the default password? Will they pick a password that is difficult and time-consuming for an automated attack to crack?

The answer is for developers to set up their connected devices in the most secure state by default, and then systematically open up security in a way that maintains security while letting authorized users access the devices. High velocity, automated hacking is the norm, so developers working with connected devices and services should make security their norm. As a user, best practices are to take the approach of setting up your connected device in the most locked down state, and then deliberately and systematically opening up network functions following a secure protocol.

Here’s a simple checklist:

  • When starting, turn off all services, including port forwarding. If a setting is available to put the device into a lock down state where it doesn’t interact with the outside world, turn that on.
  • Update the firmware.
  • When activating a network service, configure the minimal permissions to get the communication task done.
  • Change any default passwords.

This is a good starting point for basic security on connected devices and services. Developers don’t specialize in security, but by following this checklist, they can avoid some of the easy-to-avoid vulnerabilities common to setting up connected devices and services.

And never, ever use the default password.

This UrIoTNews article is syndicated fromDzone