5 best practices for making smart-building LANs more secure

Power, they say, corrupts, and absolute power corrupts absolutely. While that was said about politics, it sure seems like it was tailor-made for smart buildings.

Facility-control technology is exploding because the concept is useful and often saves money. Unfortunately, smart devices have also proven to be an on-ramp for major intrusions. Smart buildings are surely absolutely powerful in a way; are they absolutely corruptible? Maybe, if we’re not very careful.

If corruption means overall bad-ness, then hacking a smart building surely qualifies. It could let intruders mess with lights, heating and air conditioning, and maybe other critical systems, too. We also know from news stories that a hacker could use a successful smart building intrusion to sneak into other business applications, potentially compromising them and  critical company information. It’s important to address these risks, and that means starting with how they arise.

Hacking generally needs something to hack through, and smart buildings create two broad attack surfaces to worry about. The first is the interface through which the building is controlled, often a phone or browser. The second is the interface to the smart elements themselves, the protocol used by the IoT devices. The risk to each of these depends on how your building intelligence is organized.

There are two basic models of smart buildings, what you could call the military model and the mob model. Have you ever watched a parade where the military marched? There’s a big group, but they’re all marching in step based on some leader who counts cadence. That corresponds to the local-controller model of smart buildings; there’s a leader running things. Now consider the parking lot as a big event is letting out. Everyone-for-themselves doesn’t begin to describe how that usually turns out, and that corresponds to the autonomous-device model of smart buildings.

One reason the model is important in security is that the smaller and cheaper something is, the harder it is to secure. In the local-controller military model, all the smart IoT elements connect with a local device that provides the link between the smart building and the phones or keypads or switches that provide the human interface. There is one control interface, which means only one control point to defend against attack, and it’s pricey enough to get good security.

The autonomous-device “mob” model lets individual devices do their thing, usually with their own independent app. Your doorbell camera or thermostat is an example; each works through its own app, connected either via your LAN or remotely using the Internet. That means that every device is potentially accessible to intruders. Since the devices are small, low-powered, and inexpensive, they’re less likely to have robust security than a local controller, and even if they’re used with a robust local controller, the controller usually connects through each of those separate apps, so there’s no security gain.

Real security for smart buildings starts by adopting the local controller model for all devices, particularly for large and complex facilities. With a proliferation of Wi-Fi autonomous devices, the number of possible attack points is simply too large to manage. With a local controller, you have one control interface to watch, one primary software element that connects the building to the control interface. It’s much easier to protect that, and to ensure that the software and any firmware are kept up-to-date.

The controller model also helps with the security of the IoT links. Controller-based smart buildings use a custom IoT protocol (common ones are LoRa, LoRaWAN, Z-Wave, and Zigbee) with limited capabilities to limit how they could be exploited, so even if the device link was hacked, there’s a limit to what damage could be done. The Internet and LAN are firewalled from the devices by the controller, making it much harder for an intruder to ride into the building by hacking an IoT device. Best of all, modern versions of the IoT protocols are themselves encrypted, which means that even if those protocols can reach outside the building, they’re very difficult to hack. The system isn’t foolproof, but it can lower the smart-building hacking risk to the point where it’s as low or lower than other hacking risks you already face.

“Can” is the operative word here. It’s essential to take some basic steps to ensure that the controller model achieves everything it’s capable of:

• Review controller features carefully, looking for specific tools to manage updates, but also basic features like firewalls and encryption on the web/LAN interface used to control the building. Another helpful feature is journaling of activity, particularly commands. Regular review of a journal can help spot attempts to hack the system or just do something naughty.
• Know your device vendors and their practices. Review how firmware and software for your smart building components are kept up to date. Can you interrogate every device to learn its firmware? Does the manufacturer provide firmware updates regularly? Are your smart components from a reputable vendor with solid financials, so you don’t have to worry about their going out of business?  Is there a federation that certifies smart devices for the protocol you’ve picked, and is your vendor a member?
• Avoid using WiFi-connected devices with your smart building controller. That would open a new interface, creating a new point of attack. Most Wi-Fi devices still require their original control connection, too, which creates a path through which to attack the controller.
• Consider partitioning your most critical IoT elements onto their own controllers. Things that are regularly manipulated by occupants, like lighting, should be separated from control of critical facility resources like heat/air-conditioning, elevators, etc. IoT sensors used to warn of abnormal conditions, and security systems, should always be kept separate to reduce the risk of gaining entry to a critical system through a routine, often-used, path.
• Separate routine controller access from administrative access on all controllers. Most IoT controllers used in smart buildings are designed to be programmable so that they can control the facility even if no user is connected via phone or browser. If anyone who can access the controller can write or change programs, upgrade software, etc., then the controller is not secure. For even greater security, provide routing facility control only via keypads or other limited-feature devices, and use phones or PCs only for administrative functions.

Don’t be afraid of smart building technology; properly used it can actually enhance security by letting you review how your facility is being used, and sometimes even by whom. But remember my military analogy; if the wrong person is giving the commands, the whole formation can march over a cliff like proverbial lemmings. Follow these tips so you won’t join them.