The recommendation is to segregate the devices. Not just stick them in another subnet, and not to put them in another segment with what needs to talk to them being dual-homed with routing preference. There should be a device which can handle ACLs between the IoT devices and the remainder of the networks. Most prosumer routers are not capable of this. The irony is that the SOHO routers with a "guest" network do actually create a segment behind a different NAT and no devices on the inside network can talk to the gust network without passing through a gateway and vice versa.

In order to do the segment properly, you need a router with ACLs, you know, a firewall. You can easily turn an old PC into a gigabit firewall using PFSense or something similar. And if you don't have the luxury of running separate fiber/copper for each network, VLANs work great. You can pick up a used Cisco 3560G for ~$100. Ubiquity gear will let you run multiple SSIDs each with their own VLAN. Once trunked back to the switch and firewall, you have the segmentation. You can quickly write the rules that trustedNet -> IoTNet allowed, and IoTNet -> trustedNet allowed w/ related established. The crappy part is that most of these IoT devices rely on protocols like Bonjour to play nicely with all of your other devices. Without running avahi or something similar, those packets will stay in the IoT network. That is actually preferable for security's sake, but makes things less user friendly. So you either run avahi or put anything that you want to be able to communicate and sync via service discovery protocols in the IoT net.

The actual segmentation is easy. The making the devices work the way they were intended once segmented, well that is a real pain.

As for Apple devices not belonging in the enterprise - I disagree. As do many of the Fortune 500. Apple TV's have made it incredibly easy and affordable for companies to set up collaboration suites and use screen casting to rapidly share data on commodity screens among people without having to snake cables all over the room. There are multiple ways that organizations choose to secure this, but generally if patching is done in a timely fashion, and the device is appropriately limited in communication, they pose about as much risk as a network connected printer. As for their computers, well you can't really get any worse than the current choice for enterprise desktops.

I was part of a national infraguard committee a couple of years ago where we wrote about this and made real suggestions including examples on how to do this in response to rise in IoT malware like Mirai. Unfortunately, through bureaucracy and watering down to not show disdain for this company or that - the world got this recent recommendation which was terribly unclear and not terribly helpful.

That is a long winded post to not answer the original question, but I wanted to provide some background and intent as one of the committee members tasked with making recommendations to the InfraGuard powers that be on securing IoT in the wild. If you have never experienced an InfraGuard national level committee, well, I am not sure how to describe it as anything other than "an experience." If you are not a part of InfraGuard, consider joining. Sure they put out some "intelligence" this is not always that intelligent. They put out some IoCs that vendors published months ago as well. They also publish reports that are non-specific compilations of general trends and threats to specific industries and sectors that are quite good when used as data points in a mature CTI program. It is also a great way to establish contact and relationships within DHS and the FBI. Knowing them before the breach is important. Also, they know which companies are worth working for, what the average entrance pay is, and who is hiring because they interface and talk with both cyber and physical security teams regularly.

Mac

Thomas Scott wrote on 12/9/19 8:48 PM:

@Michael - to remedy this, I've seen customers deploy things like super flat topologies with VPLSs to tie it all together. It's always fun to have to increase someones's mac table size as their apple TVs were edging out their DHCP servers. I know you're paying me to do this, but an obligatory "Your network is bad, and you should feel bad" is always on the tip of my tongue. 

Thomas Scott about.me/thomas.scott

On Mon, Dec 9, 2019 at 10:14 PM Matt Graham <mhgraham@crow202.org> wrote:

On 2019-12-09 19:39, Michael Butash wrote:
> Linux networkmanager will assign a higher metric on non-ethernet
> interfaces (ideally) to de-preference wireless over wired, but they
> still both get an address.  In the same subnet, the metric is what
> determines preference.  You can tweak metrics, but usually depend on
> the network interface and system preferences.

This makes sense.  The machine where I had 2 NICs on the same subnet, 1
wired, 1 wireless, had the wired NIC with metric 203 and the wireless
one with metric 304 in the output from "route -n".  Network Manager was
not involved; just dhcpcd.  OTOH, dhcpcd probably understands what
"wired" and "wireless" are and sets up the routes and metrics
accordingly.  I think that if I set the metrics for enp1s0 and wlp3s0 to
the same number, I'd get the terrible network problems I described
earlier.

> This has been a problem for decades, but generally managed by
> networking stack setting metric preference on routes.  Wired == best,
> wireless, vpn, others, less. [...] This is standard networking.

This is actually the first time I've heard of the "metric" thing in the
kernel routing table.  This is probably because almost all of the
machines I've dealt with over the last 20 years have had pretty simple
networking configurations.

--
Crow202 Blog: http://crow202.org/wordpress
There is no Darkness in Eternity
But only Light too dim for us to see.
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss