I worked on a safety critical system in which we designed security and fail safe right from the beginning. Hardwired state machine controllers for things that could explode. The hardware engineers think that way (thankfully) so we should too. After I left they junked it all and replaced it with Siemens "HMIs" (very expensive Windows XP systems), fancy process control stuff, and then spent even more on fancy consultants every time they wanted to make a change. But at least it was familiar. (I could still access the systems long after I'd left). At least it explains why the real hardware guys (as in actual iron) don't trust the silicon jockeys or software guys: what they have access to us crap.

Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation!

Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them?

The problem is Industrial engineers aren't IT or security experts and that's why we have security issues. Plus they're under constant pressure to get production running and meeting deadlines. Next you'll say "but what about stuxnet! that proved that even air gapping isn't secure enough!" Yup. It also proves that using insecure general purpose operating systems (hint, windows) is stupid as well. But it's cheap and familiar so here we are. The problem isn't with the protocols or hardware, it's ignorance with a side of laziness topped with corner cutting.

Also many industrial protocols don't run over tcp but instead use raw ethernet packets and have dedicated protocol processors running to keep latencies down to microsecond levels for flipping IO bits. An example is Beckhoff's EtherCAT. So security does not apply to those networks and would be difficult to implement.

> Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation!

Apples to oranges.

We recently bought a machine which has an internal automation network between a Siemens 840d, a Siemens safety PLC and a DSP controller from Adwin. Real time communications is over Profibus and CANopen. between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine. I'd trust that more than any home automation built on webshit.

Clearly stuxnet is a myth and bedtime story to frighten children with.

What hardware + hardened OS would you recommend for jump boxes? OpenBSD, Linux, pfSense?

As for our 3rd party machines with jump boxes: I view jump boxes as a security risk if directly connected to corporate lan as they can bypass firewalls. So I kept it simple and created an isolated jump box network from the pfSense that gives them 24/7 remote internet access with zero ability to see anything on the company lan.

Our Internal machines are on an isolated network, all hardwired and have static IP addresses, zero internet access. The engineers frequently have to write new CNC programs so I make it easy to share files while isolating the networks; I bridged them using a Debian server running a SAMBA server with two network interfaces. One is connected to the company lan, the other to the dedicated machine lan. The file server has a single share for the engineers with RW access and each machine gets RW access only to its directory in that share. Operators go to the P (program) drive and retrieve the programs. There is no network bridging or routing between the two networks. As far as they know, it's just a file server. That network also terminates in our office and we can connect to it for programming and troubleshooting.

One Idea I've been toying with is developing an internal jump box that allows our machines to connect to the corporate lan giving engineers file access while maintaining network isolation. That way I can ditch the second network and go DHCP with reservations all around.

If a fileserver vulnerability helps an attacker to take control of the host, they may be able to move traffic between the network cards.

Might be better to have two file servers. The less-exposed server could periodically connect to the more-exposed server to sync files. Would not need open ports on the less-exposed server.

"Remember, S in IoT stands for Security."

I have achieved a decent level of automation using simple timer switches (they have ones that adjust on/off times based on your latitude), completely disconnected motion sensing lights, and by simply reading the manual on how to program my thermostats.

I have considered using ZWave to enable me to use some cron jobs or openHAB, but I will not use WiFi.

HomeKit and ZWave don't require an Internet connection. I use a bunch of ZWave devices connected via Ethernet through a Raspberry Pi with hassio and a ZWave USB adapter - controlled from my phone when it connects to my wifi network.

To protect your wifi network, make sure you have a decent gateway in place. OpenWRT does a great job, but there are many others as well.

It's too bad people forgot how to make and sell a thing, and instead are selling a (surprise!) business model.

In our neighborhood, we've had quite a few thefts of skiboxes (the ones that go on top of the car) recently, and several say the security cameras seemed to be unconnected at the time, hinting at some use of de-auther/jammer.

There's also "hybrid" options for usecases like the "unconnected camera": a wireless camera that has local storage, for example.

That's because we do it stupidly. Why are we running wires in walls where we can't ever get at them? Trim and quarter round could double as conduit.

https://developer.apple.com/support/homekit-accessory-protoc...

>[HomeKit Accessory Protocol] supports two transports, IP and Bluetooth LE.

i'd rather receive a potato with a telnet chip jammed into it because at least i can turn it into gnocchi.