It's time to talk about Security on our networks.

[Rob]

Have you heard about California Civil Code Title 1.81.26, Security of Connected Devices?
Pathway Connectivity, a division of Acuity Brands, is prepared. Read all about it here.
This light-hearted video from the #LDI New Product Breakfast introduces security measures that we have implemented to protect your products and production.

 

[Jay Ashworth]

You realize the Max Headroom Incident was 32 years ago last week, right?

 

[Jay Ashworth]

And a reminder to people deploying that gear:

Don't run a WLAN stomper unless you have *full* administrative control of the physical space...

 

[CrazyTechie]

Don't run a WLAN stomper unless you have *full* administrative control of the physical space...

If you're talking about what I think you're talking about, it's illegal to do that to begin with. https://www.fcc.gov/document/warning-wi-fi-blocking-prohibited

 

[Jay Ashworth]

Hotels and convention centers.

That would be a real stretch to expand to (owned) office buildings and college campuses.

 

[MNicolai]

WiFi blocking via RF is illegal. Full stop. Doesn't matter if it's issuing deauth packets or RF jamming.

Blocking rogue WAP's that are attached to your own network, from connecting to your network, is legal.

The difference is one is a network you own, and you have a right to deny access to it. The other entails disrupting networks that do not belong to you, which you hold no right to interfere with.

Who owns the land or buildings under the WiFi has no influence on what you can or cannot get away with.

 

[Jay Ashworth]

Better not tell *any* of the managed WLAN equipment providers (notably Cisco and Ubiquiti), who not only still ship it, but still *market* it.

And, if I was the Network Administrator of a facility handling confidential material... you'd better not tell me, either.

The decision mentioned above appears to *specifically* apply to mixed-use/ownership spaces. So far as I know, it does not apply to the general case, and if the general case was a violation of FCC regs, those manufacturers wouldn't be flacking it.

 

[CrazyTechie]

Sure, but selling the technology isn't illegal. I agree that it doesn't make sense that all of these enterprise manufacturers would sell and market a technology that's illegal to operate in the US, but then again, it may be legal elsewhere. It's up to the individual network operator to be in compliance with the laws.

If we take a look at the public notice I linked to, it states:

Willful or malicious interference with Wi-Fi hot spots is illegal.

There's also Section 333 of the Communications Act that applies specifically to this which states:

No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government.

WiFi would fall under the authorized portion of that section, since it's not a licensed form of communication. So, this applies to everyone. There is no loophole here.

 

[RonaldBeal]

"Jamming" wi-fi in the U.S. is illegal. Full Stop. Even law enforcement must get a specific waiver from the FCC to jam anywhere. (There are some specific short term waivers pre-granted for immediate national security issues, but that is about it) I
The Gaylord Opryland Hotel in NAshville, TN was recently fined $600,000 for doing so illegally.
Story here: Link
It is not illegal however, to kick off unauthorized traffic off of a network you manage.

 

[Jay Ashworth]

Here's a Network World piece on the topic:

How not to get slammed by the FCC for Wi-Fi blocking

Partners Healthcare's wireless communications manager offers advice for navigating WiFi waters

www.networkworld.com

with this quote:

Comparing the operation of an IPS’s deauthentication feature to the definition of harmful interference, it’s easy to see that if someone intentionally deauthenticates someone else, the person doing the deauthentication is causing harmful interference. That said, the FCC doesn’t require you to share your network with everyone else, so using an IPS to deauthenticate unwanted wireless user devices from YOUR network is legal. Using an IPS to deauthenticate unwanted wireless users from THEIR network is illegal.

The FCC has known about IPS offerings since they first came out. If the Commission believed their existence were illegal, they would have forbade their marketing, importation, sale and use from the very beginning, as they already do with all other forms of jamming devices. The Commission understands IPSes have a legitimate use. Thanks to Marriott, the Commission and everyone else now understand IPSes can have an illegitimate use.

But that's a red-herring. It's not *necessary* to use that feature of an IPS to knock people off a WLAN you control -- you just MAC block them... if you're not running 802.1x, which is first-grade stuff if you're actually concerned with this topic in the first place.

So no, that's not evidence that "IPSs have a legitimate use".

Has anyone got any pointers to *actual enforcement action* by the Company since the Big Hotel Fiasco?

 

[Jay Ashworth]

And it's pretty clear the FCC does *not* classify IPS eqipped WLAN systems as "jammers", because:

https://transition.fcc.gov/eb/jammerenforcement/jamfaq.pdf

Yes, those *are* illegal to sell in the US.

 

[dvsDave]

Have you heard about California Civil Code Title 1.81.26, Security of Connected Devices?
Pathway Connectivity, a division of Acuity Brands, is prepared. Read all about it here.
This light-hearted video from the #LDI New Product Breakfast introduces security measures that we have implemented to protect your products and production.View attachment 18855

Looking at California Civil Code Title 1.81.26, Security of Connected Devices?

(1) The preprogrammed password is unique to each device manufactured.

That could get onerous real fast for things like lighting fixtures. Or would it even apply to them?

 

[MNicolai]

I don't think the password clause applies to most lighting devices except probably architectural processors. The scope of that item is in reference to devices capable of authentication outside a local area network.

​

(b) Subject to all of the requirements of subdivision (a), if a connected device is equipped with a means for authentication outside a local area network, it shall be deemed a reasonable security feature under subdivision (a) if either of the following requirements are met:​

​

(1) The preprogrammed password is unique to each device manufactured.​

​

(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.​

The aim of that clause was aimed at devices like Cisco's switches which ship as user/pass cisco/cisco, and way too many people leave them defaulted to that. Not throwing Cisco under the bus specifically. Everyone is guilty of it and home wireless routers and NAS drives are probably some of the most susceptible devices to being left on default credentials and accessible to an attack.

 

[DrewE]

Looking at California Civil Code Title 1.81.26, Security of Connected Devices?

(1) The preprogrammed password is unique to each device manufactured.

That could get onerous real fast for things like lighting fixtures. Or would it even apply to them?

It would not apply to DMX512 control. "Connected device" is defined thusly:

“Connected device” means any device, or other physical object that is capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address.

A DMX512 address is neither an IP address nor a Bluetooth address; hence, a standard theatrical lighting fixture is not a connected device.

 

[danTt]

It would not apply to DMX512 control. "Connected device" is defined thusly:

“Connected device” means any device, or other physical object that is capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address.

A DMX512 address is neither an IP address nor a Bluetooth address; hence, a standard theatrical lighting fixture is not a connected device.

Now, it gets a bit more interesting with sACN/artnet native fixtures and consoles, which are capable of these things.

 

[Rob]

Now, it gets a bit more interesting with sACN/artnet native fixtures and consoles, which are capable of these things.

The law states
"Connected device" is defined as any device that is capable of connecting to the Internet, directly or indirectly..."
It's the the word indirectly that is particularly troublesome. If you're using DHCP or specify Address|Subnet|Gateway, this law applies.

 

[dvsDave]

The law states
"Connected device" is defined as any device that is capable of connecting to the Internet, directly or indirectly..."
It's the the word indirectly that is particularly troublesome. If you're using DHCP or specify Address|Subnet|Gateway, this law applies.

Oh that just sounds "fun". Especially since almost anything is indirectly capable of being connected to the internet. Would your collaboration with SixEye be considered a gateway for these devices?

 

[Rob]

When I said Gateway, I meant a route to the Internet on the local NIC of the device (i.e., Address|Subnet Mask|Gateway). Yes, SixEye needs a gateway to get to the cloud, but I don't want to confuse this new Remote Monitoring technology with a specific piece of hardware. The SixEye implementation has advantages over locally placed PCs that monitor devices on a LAN and report upward. ALL our devices make their OWN connections to the cloud, so your only point of failure is the local 'guest' network connection or LTE router.
As far a security is concerned in regards to SixEye, it exceeds any standards dictated by the likes California Civil Code Title 1.81.26.
Here are some bullet points from the SixEye website.

• SixEye uses industry-standard network security protocols & encryption algorithms for device connections and your portal. Data is encrypted in motion and at rest.
• No VPN required, no ports to be opened, and no firewalls to be compromised. Works over any Internet connection; devices only make secure outbound connections.
• Your data is private, and your data is protected. We will not share it for commercial purposes.

 

[RickR]

"We will not share it for commercial purposes. "

Pardon my cynical nature:

• You might get hacked.
• You might share with someone that gets hacked.
• You might share with someone that breaks a contract.
• One of your partners shares with one of their partners who...
• You might decide to change your policies and we fail to notice the legal notice.

 

[dvsDave]

"We will not share it for commercial purposes. "

Pardon my cynical nature:

• You might get hacked.
• You might share with someone that gets hacked.
• You might share with someone that breaks a contract.
• One of your partners shares with one of their partners who...
• You might decide to change your policies and we fail to notice the legal notice.

By the same token, you could say that about ControlBooth. We take great care and effort to ensure data security, but nothing is able to be a 100% guarantee. A zero-day exploit could target our server, even though we are diligent about keeping it up to date. Best we can ask for is a policy that states our goals and an understanding that it would hurt us, as much, if not more than our customers.