Building a secure smart home - Introduction

Smart home technology can be super fascinating - being able to program and control everything in a home is one of the coolest ways to bring the power of programming into everyday life. However there’s a big issue with so many connected devices in a home: A lot of them have some severe security flaws, so connecting them to the internet is not the greatest idea in terms of network security.

Therefore, after being inspired by some of my colleagues’ blogs, I decided to build my own smart home solution, with security in mind from the very beginning.

This post is the introduction to a series of articles, each containing a new step to a (mostly) automated home. Where applicable, I’ll share code snippets and create video documentation of the setup / build process. Feel free to follow along!

Here’s what you’ll find in the first part:

• End goal of the project
• Network & security architecture
• Threat model elaboration
• Automation considerations

The Goal

There are four main building blocks in this smart home project that form its most important decisions:

• Security
  The design should be secure against a set threat model. Where possible, the smart home system should be separated from the internet wherever possible. There will still be a connection since some actions need access to external services, but that’s way better than just connecting everything to the internet. Which brings us to the next building block:

• Use of and compatibility with (external) APIs
  Building a new system from scratch is nice and all, but some services aren’t really feasible to host locally. Integration with Spotify or a voice control service like Amazon Alexa come to mind, or even more simple things like the current weather report. This smart home system should be compatible with APIs as much as possible, both in the internal network and over the internet.

• Automation
  Well, what’s any cool soft- and hardware project without some fun automation? Imagine this: You come home in the evening, open your front door and the lights immediately turn on, your room is at the perfect temperature and your favorite playlist starts playing. Or you go to the bathroom at night and instead of shining a blinding light into your eyes, the ceiling lamp just emits a dimmed shine that lets you get back to sleep more easily. In the morning, you wake up to lights slowly fading in and coffee that is already done when you need it. All of this can be done with some programming, and it really is super rewarding once it works.

• Ease of use
  Between all the programming, it’s easy to forget to keep it simple and accessible. If it’s just me at home, I don’t mind turning off the lights manually via a command line, but having a phone app to do this makes for a much nicer experience (at least for most people). And that’s what it’s all about, isn’t it?

Architecture

Just a few years ago, many home networks looked quite simple. They mostly contained a (possibly WiFi-enabled) router, a few computers, mobile devices, and maybe a server. A ‘classical’ home network might have looked like this:

In recent years, this has changed dramatically in many households. A smart speaker here, maybe some connected lights, and the shiny new car has WiFi too! Suddenly, a home network looks way more crowded:

With so many IoT-devices (IoT = Internet of Things¹) in the network, there is a significantly higher risk that one or more of these devices are vulnerable to remote attacks and could act as an entry into your network to hackers.

There have been many examples of this in the past, including the Mirai² Botnet, compromised pacemaker devices³ and several types of security cameras that could be accessed remotely by anyone⁴ without authentication.

To avoid encountering those issues, three different types of measures are being taken in this project:

1. Network segmentation
   The first step in a secure home network with IoT-devices is to separate them from critical devices, such as Personal Computers and Servers. If separated properly, a successful compromise of a smart home device has a much smaller impact than without network segmentation.
2. Use of hardened devices
   In order to avoid being compromised in the first place, it is a good idea to use devices with increased security. The bar in IoT is not set very high, so this is extra-important. Hardening steps include changing standard passwords to unique, secure passwords, avoiding external online services where possible and limiting who can access the devices. This will be done in more detail in upcoming blog posts.
3. Traffic monitoring
   Monitoring the traffic in the network does not help much with preventing a compromise, but it aids with detecting anomalies that indicate a possible ongoing or successful attack. If an attacker is detected quickly after obtaining initial access to the network, it is much easier to restrict lateral movement options, making it more difficult for the attacker to “jump” from machine to machine and eventually find important stuff. Monitoring the network traffic is most often not needed in a home network setting, but it is a great platform for learning how some enterprise-grade security tools work. Those tools will also be addressed in-depth in future posts.

Taking into account the measures mentioned above, an architecture for the example network introduced in this article could look something like this:

In this case, a dual-homed smart home hub system with a firewall is used to connect the two networks. It should be noted that dual-homed systems introduce their own security challenges, but those will be dealt with in future articles.

Over the course of this blog series, a similar architecture and its components will be implemented.

While this architecture is already significantly more secure than the chaotic network shown above it, there is no such thing as perfect information security. If an attacker is motivated and skilled enough, it is likely that they would still be able to gain access to the network. Since it is not feasible to spend an infinite amount of time and effort on securing this home network, it is useful to do a little exercise in threat modeling.

Threat model

This section contains a brief exercise in threat modeling⁵. This is done in order to analyze the risks of the architecture to be compromised by a defined threat and what impact such a compromise has. If you’re interested in reading about an in-depth threat modeling exercise, I recommend checking out this article.

To determine what level of security is sufficient for this network, it’s critical to know what the architecture and components are up against. In this case, protecting against nation-state attackers putting in massive resources to attack the network is not very useful, since the much easier path for such a motivated malicious actor would be to gain access to the physical home when nobody is there. On the other hand, just protecting against automated exploitation attempts is not nearly cool enough for this blog. In my opinion, focusing on a threat that is just barely not motivated enough to physically break into the home and has the security knowledge of a network penetration tester is a good exercise. We’ll call this malicious actor APT-HOME. (APT is short for Advanced Persistent Threat⁶)

When attempting to compromise the network, APT-HOME has a specific modus operandi (way of working, more on this topic in future posts). For now, this is the definition of this modus operandi:

• identify remotely accessible devices in the network
• scan those systems for common vulnerabilities
• exploit vulnerabilities if public exploits are available
• move laterally through a network by scanning and exploiting as described above
• exfiltrate any personal or sensitive data

After defining this and analyzing publicly available data about successful compromises through IoT, completely separating all smart home devices from the internet appears to be very useful in defending the network against APT-HOME. Without being able to reach them directly, the attacker cannot identify possible vulnerabilities. Of course, this does not mean that no security patches need to be rolled out to devices in the network separated from the internet, it simply reduces the size of the attack surface.

Having determined that reducing the amounts of web-reachable machines is a good idea, let’s assume that one of the devices that are connected to the internet gets compromised by APT-HOME. A possible scenario for this could be that a VPN server in the trusted network is not patched against a newly released exploit in time, allowing the attacker to get access to it.

With access to a server in the trusted network, the malicious actor continues to scan the internal network. Assuming that one system is not patched well enough, monitoring of network traffic is the last barrier in defending against APT-HOME. Detection of scanning activity using common tools such as Nmap, Nessus or Metasploit should be sufficient against the modus operandi of this specific attacker.

Having run through a brief set of scenarios, some concrete measures can be defined to protect against the threats defined above:

• Separate IoT devices from the internet
• Keep all systems patched as good as possible
• No ports should be exposed in the trusted network unless they’re critical

This incurs that a dual-homed hub connecting the IoT-net to the trusted network should only be directly reachable locally or through a VPN, even though that might make some things more difficult when implementing the smart home functionality.

This concludes the short expedition into the world of threat modeling. But fear not, APT-HOME will return in the future!

Automation

Coming back from some abstract security considerations, this section comes much closer to the actual implementations. A smart home is good if you can control everything from your phone, but a great smart home needs almost no control input in the first place. The key to success here is therefore automation. Creating an environment where automating actions with different in- and outputs can be done easily is best done without reinventing the wheel. Choosing an architecture where a hub is dual-homed in both the trusted and untrusted network suggests using this hub for the majority of automation tasks, instead of having the smart home appliances figure that out in a decentralized fashion.

A software like node-red is a good choice in this case, as creating automation patterns is as simple as clicking together flows, leaving more time to build and implement the actual smart home devices.

Conclusion

After the first article of the series, a network security architecture that is resilient against an APT-HOME-level threat has been discussed and established, and an idea of how an automation setup could look like has been formulated as well.

The next part of this blog series is going to cover setting up the network and the central hub system. It will include detailed procedures and code snippets where applicable, so if you’ve always wanted to build a smart home system yourself, this is your chance to get ready! It’ll be out as soon as I have some free time to write it, so stay tuned! Updates of this blog will be posted on my Twitter account, it’s linked below if you’re interested.

Footnotes and further reading

---